Next.js WebSocket SSRF exposes internal resources without auth

At a glance

What this is: This is a vulnerability alert about a Next.js WebSocket SSRF issue that can expose internal resources without authentication.

Why it matters: It matters because internal access control assumptions can fail when public-facing services are allowed to relay requests into trusted environments without strong validation.

Context

Server-side request forgery is a control bypass problem, not just an application bug. It occurs when a server is tricked into making requests that the attacker could not make directly, often crossing from an exposed endpoint into internal services or metadata systems. In this case, the concern is especially relevant because a WebSocket path can become a trusted relay into internal resources.

For IAM and NHI practitioners, the identity angle is indirect but real: SSRF often becomes dangerous when internal services trust source location instead of authenticating each request properly. That creates a gap between network placement and access governance, which is exactly where machine identities, service endpoints, and internal APIs become exposed.

The article frames a common weakness in modern application estates. Teams frequently assume that being behind a private network or behind an application boundary is enough, but runtime trust still has to be enforced per request and per service interaction.

Key questions

Q: What breaks when WebSocket SSRF is not blocked at the server layer?

A: The application can be used as a relay into internal services that were assumed to be unreachable from the internet. That breaks the boundary between public input and private resources, which means internal APIs, metadata services, and admin paths can be exposed without the attacker ever authenticating to them directly.

Q: Why does unauthenticated SSRF still matter when internal services are behind a private network?

A: Because private network placement is not an access decision by itself. If the server can make the request, the attacker can borrow that trust path, so internal resources need service-level authentication and explicit destination controls rather than reliance on location alone.

Q: What are the signs that a WebSocket endpoint may be unsafe to proxy through?

A: Look for handlers that accept user-controlled hostnames, URLs, backend IDs, or connection parameters and then translate them into outbound requests. The risk is highest when the same path can reach internal-only hosts, cloud metadata services, or admin endpoints without strict validation.

Q: Should teams treat SSRF as an application bug or an access control problem?

A: Both, but the governance failure is the deeper issue. SSRF becomes an access control problem when the application is allowed to mediate requests into trusted systems without proving who is allowed to use that path and what destinations are permitted.

Technical breakdown

How WebSocket SSRF turns a public endpoint into a relay

WebSocket-based SSRF happens when a server accepts attacker-influenced connection details or routing inputs and then opens outbound requests on the attacker’s behalf. Because the request originates from the application server, the target sees a trusted internal source rather than the external attacker. That can bypass perimeter assumptions, internal allowlists, and service segregation when the application is allowed to reach sensitive hosts or metadata endpoints. The risk is amplified in frameworks that support flexible proxying or dynamic backend selection, because the server becomes a transport layer for attacker-controlled destinations.

Practical implication: Restrict server-side egress destinations and validate every upstream target before a WebSocket request can be relayed.

Why authentication does not stop an SSRF pivot

SSRF is often exploitable before any user authentication matters because the vulnerable behaviour sits in server-side request handling, not in the user session layer. Even authenticated-only endpoints can be unsafe if the server accepts a request that causes internal network access on the user’s behalf. In practice, the application’s own credentials, trust zone, and network position become the attacker’s tools. This is why access control must cover outbound server requests as well as inbound user access, especially where internal APIs, admin interfaces, or metadata services are reachable from application hosts.

Practical implication: Treat outbound server requests as a governed access path and authenticate each internal hop explicitly.

Internal resources, service trust, and the hidden access boundary

The real issue is not simply that an internal URL can be reached. The issue is that internal services frequently treat the application tier as inherently trusted, so one compromised request path can expose configuration data, credentials, or privileged control interfaces. In cloud and container environments, that can extend to metadata services, service meshes, and internal APIs that were never meant to be internet-adjacent. The control failure is a missing boundary between externally influenced input and internally trusted resource access, which is where runtime policy and service authentication have to do the work network placement used to do.

Practical implication: Enforce service-to-service authentication and block direct access from application tiers to sensitive internal endpoints.

Threat narrative

Attacker objective: The attacker wants to pivot from a public web surface into internal resources and retrieve data or control paths without authentication.

1. Entry occurs through a crafted WebSocket SSRF request that causes the server to make an outbound call on the attacker’s behalf.
2. Credential access or sensitive retrieval can follow if the request reaches internal services, metadata endpoints, or privileged administrative interfaces.
3. Impact is unauthorized exposure of internal resources that were assumed to be reachable only from trusted network locations.

Breaches seen in the wild

• Capital One breach 2019: A misconfigured firewall handed over its cloud role credentials, and an over-privileged role exposed data on 106 million people.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime trust, not network placement, is the real control boundary. This class of SSRF shows that being inside a private network does not equal being authorised to reach internal resources. Service placement, proxy behaviour, and application routing all need explicit governance because the attacker can exploit the application as a trusted intermediary. The practitioner conclusion is straightforward: treat internal reachability as an access decision, not a topology accident.

WebSocket handling broadens the attack surface because it often blends long-lived connections with server-side routing logic. That combination makes request validation more difficult and expands the chance that a single malformed connection can persist long enough to reach sensitive endpoints. For identity and access programmes, the lesson is that transport flexibility should not weaken request-level authorisation. The practitioner conclusion is to govern server egress with the same discipline applied to inbound authentication.

Internal APIs and metadata endpoints need service-level authentication even when they are not publicly exposed. Many environments still rely on location-based trust for internal services, and SSRF breaks that assumption by letting an attacker borrow the server’s position. This is a classic access governance gap in cloud and application estates, not merely a code defect. The practitioner conclusion is to make every internal service prove who it is talking to before it returns anything sensitive.

Next.js WebSocket SSRF is a named example of internal access control collapse. The specific failure mode is unauthorised request mediation, where the application becomes a bridge into trusted systems without a corresponding authorisation check. That is the concept teams should monitor across similar architectures, because the same pattern recurs anywhere a server can translate external input into internal reachability. The practitioner conclusion is to hunt for mediated access paths, not just vulnerable endpoints.

What this signals

Internal reachability has to be governed as an authorisation decision. When a public application can translate untrusted input into internal requests, the old assumption that network location equals trust no longer holds. Teams should look for mediated paths in WebSocket handlers, proxy code, and metadata access patterns, then apply destination allowlists and service authentication where those paths exist.

Server-side request forging patterns often expose a broader control gap than the individual vulnerability suggests. The meaningful question is not only whether the endpoint can be exploited, but whether internal services are prepared to reject unauthorised callers even when the request originates from an application host. That is where identity security, application security, and cloud segmentation converge.

For practitioners

• Block untrusted internal destinations Constrain server-side egress so application code can only reach explicitly approved hosts, ports, and protocols, especially where WebSocket handlers can proxy requests into internal services.
• Require service-to-service authentication Make internal APIs, admin interfaces, and metadata services verify the caller at the service layer instead of assuming that internal network location is sufficient.
• Review WebSocket routing and proxy logic Inspect any code path that turns connection parameters into backend requests, and remove dynamic target selection unless a strict allowlist and validation layer are in place.
• Separate public application tiers from sensitive control planes Place metadata endpoints, management interfaces, and privileged internal APIs on paths that the application tier cannot reach directly, even if the application is compromised.

Key takeaways

• The core risk is unauthenticated server-side request forgery through a WebSocket path that can expose internal resources.
• The control failure is reliance on network location and application trust instead of explicit service-level authorisation.
• Teams should restrict server egress, validate backend targets, and require internal services to authenticate every caller.

Key terms

• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Internal Resource Exposure: Internal resource exposure occurs when services intended for trusted network zones become reachable through an unintended path. In practice, the exposure often comes from weak request validation, over-broad proxying, or assumptions that internal placement alone is enough to protect sensitive endpoints.
• Service-To-Service Authentication: A pattern where one application or workload authenticates directly to another without a human in the loop. It is central to modern API-driven systems and depends on machine identity, least privilege, and short-lived credentials. Poor governance here creates broad exposure if a token, key, or certificate is compromised.
• WebSocket Request Routing: WebSocket request routing is the logic that determines where a bidirectional connection sends or receives data after the session is established. When routing decisions depend on user-controlled input, the server can become an unintended proxy into internal systems, which creates SSRF risk.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security and IAM practitioners connect access governance to the control decisions that matter most in real environments.