Next.js WebSocket SSRF exposes internal resources without auth

At a glance

What this is: This vulnerability alert describes an unauthenticated SSRF condition in Next.js WebSocket handling that can expose internal resources.

Why it matters: It matters because identity and access assumptions often break when externally reachable services can be coerced into acting as privileged network intermediaries.

👉 Read Hadrian's vulnerability alert on Next.js WebSocket SSRF and internal resource exposure

Context

Server-side request forgery, or SSRF, happens when an exposed application is tricked into making requests on behalf of an attacker. In this case, the problem is not just one flawed endpoint, but the way a public service can be used to reach systems that were supposed to remain internal. For identity and access teams, that matters because the request path can bypass normal user-facing controls and expose trust boundaries that were never meant to be traversed from the outside.

WebSocket handling makes SSRF more operationally interesting because long-lived connections can blur the line between legitimate application traffic and attacker-driven relay activity. The practical governance question is whether internal services, metadata endpoints, or control-plane interfaces are protected by source validation, network policy, and service identity checks. That intersection is strongest where workload identity or service-to-service authorization is expected to limit what a public application can reach.

Key questions

Q: What breaks when a public application can make unauthenticated internal requests?

A: The main failure is that external input starts inheriting internal trust. A public application can become a relay into private systems, exposing metadata, internal APIs, or admin interfaces that were never meant to be reachable from outside. That can lead to credential theft, service discovery, and lateral movement even when the initial endpoint has no valid user session.

Q: Why does SSRF matter in cloud environments with private networking?

A: Private networking does not provide security if a public workload can initiate requests on the attacker’s behalf. SSRF lets the attacker use the application as a proxy into services that assume only trusted callers exist. In cloud environments, that often means metadata endpoints, internal dashboards, or control-plane APIs become reachable through the application’s own privileges.

Q: How can security teams tell whether SSRF controls are actually working?

A: Look for evidence that untrusted input cannot change upstream destinations, that egress policies block unexpected targets, and that internal services still require authentication even when reached from inside the network. Good controls reduce both successful connections to private resources and the amount of useful data an application can return if probed.

Q: Who is accountable when internal-only resources are exposed through SSRF?

A: Accountability usually spans application owners, platform teams, and cloud security owners because the failure crosses code, network policy, and service authentication. The relevant frameworks are NIST CSF for access and protection outcomes, and NIST SP 800-53 for controls such as boundary protection, least privilege, and system and service authentication.

Technical breakdown

How WebSocket SSRF turns a public endpoint into an internal relay

WebSockets begin as an HTTP upgrade, which means a vulnerable application may accept a seemingly normal request before switching into a persistent bidirectional channel. If the server processes user-controlled destinations or headers, the application can be induced to connect to internal hosts, loopback addresses, or metadata services. That transforms the application into a relay that can probe networks the attacker cannot directly reach. The core failure is not encryption or transport itself, but insufficient validation of where the server is allowed to connect.

Practical implication: restrict outbound destinations at the application and network layers, not only at the perimeter.

Why unauthenticated SSRF is more than a routing bug

An unauthenticated SSRF condition means the attacker does not need a valid account to trigger server-side requests. That removes the first governance gate and shifts the attack into the trust placed in the application’s runtime context. Once the application can make privileged requests, the attacker may enumerate internal APIs, retrieve metadata, or reach admin-only interfaces that are otherwise invisible externally. In identity terms, the application is acting with a different trust posture than the user who initiated the request, which is why service identity and network identity need separate controls.

Practical implication: treat unauthenticated request forwarding as a privilege boundary issue, not only an input-validation defect.

Internal resource exposure in cloud and container environments

Cloud and container environments often place sensitive control surfaces behind private networks rather than authentication alone. That approach works only if internal reachability is tightly constrained. SSRF breaks that assumption by using a trusted workload to pivot toward instance metadata, internal dashboards, service discovery endpoints, or undocumented APIs. The resulting exposure can feed credential theft, configuration discovery, or lateral movement. This is why workload identity, egress policy, and metadata hardening belong in the same control conversation.

Practical implication: harden metadata access and internal service exposure together, especially where workloads can initiate outbound calls.

Threat narrative

Attacker objective: The attacker aims to turn a public application into a trusted bridge into internal resources and sensitive control surfaces.

1. Entry occurs when an attacker sends a crafted request to the public Next.js WebSocket endpoint and triggers server-side connection handling.
2. Credential or resource access follows when the application is induced to reach internal hosts or sensitive metadata services on the attacker’s behalf.
3. Impact occurs when the attacker uses that internal reach to expose protected resources, enumerate private services, or harvest data that was not meant to be internet-facing.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unauthenticated SSRF is an identity failure as much as a web flaw. When a public service can make requests into private infrastructure, the attacker is borrowing the trust of the application itself. That means network location is being treated as an access control, which is brittle in cloud and container environments. Practitioners should read this as a warning that workload trust and network reach must be governed separately.

WebSocket-based relay paths create a longer-lived abuse window than many teams expect. Persistent connections can carry attacker-controlled traffic after the initial request has passed basic checks. That makes detection harder and magnifies the value of strict outbound allowlisting, metadata protections, and internal service authentication. The governance gap is not simply input sanitisation, but unbounded service-to-service reach from an unauthenticated entry point.

Service-to-service identity must not inherit the permissions of the web tier by default. If an application can reach internal systems, the internal target should still require explicit authentication and authorisation. This is where workload identity, mTLS, and per-service policy become material controls rather than architecture preferences. The practitioner lesson is to remove implicit trust from internal-only resources.

Cloud control planes remain especially vulnerable when metadata and private APIs are reachable through a compromised request path. SSRF is often the first step in a broader credential and discovery chain because it can expose secrets, service endpoints, and network topology in one move. That is why segmentation alone is insufficient without egress control and service-level authentication. Teams should treat private reachability as an exposed asset, not a hidden one.

What this signals

Boundary trust erosion: when public workloads can reach private targets, teams lose the basic assumption that network location equals trust. That pushes practitioners toward explicit service identity, strict egress policy, and stronger internal authentication, especially where cloud metadata or admin APIs are involved.

The operational signal is simple: if a web tier can be used as a proxy, then the environment already has a privilege problem. Security programmes should track whether internal resources remain reachable only through authenticated service paths, and whether logging shows unexpected request destinations from public-facing workloads.

For practitioners

• Constrain outbound destinations for web workloads Allow only the internal and external endpoints that the application truly needs. Apply egress filtering at the container, host, and network policy layers so a compromised request handler cannot freely pivot to metadata services or private admin interfaces.
• Protect metadata and internal APIs with explicit auth Require authentication on internal services even when they are not internet-facing. Disable or restrict access paths that rely on private network location as the only control, especially for instance metadata and service discovery endpoints.
• Instrument WebSocket traffic for anomalous relay patterns Log destination hosts, unusual upgrade requests, and repeated internal lookup attempts from the same public endpoint. Alert when a single workload begins contacting many private addresses or when request parameters influence upstream targets.

Key takeaways

• Unauthenticated WebSocket SSRF turns a public application into a bridge into private infrastructure, which is an access-control failure as much as a coding flaw.
• The risk is not confined to one endpoint because internal metadata, service discovery, and admin interfaces can all become reachable through the compromised request path.
• Teams need explicit egress control, internal authentication, and service identity protections to stop private reachability from becoming a security blind spot.

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.
• WebSocket Upgrade: A WebSocket upgrade is the handoff from HTTP to a persistent bidirectional connection. In security terms, that persistence matters because once the session is established, attacker-controlled traffic can flow through a channel that may have passed only minimal initial validation.
• Egress control: Egress control is the policy layer that governs where a service can send outbound traffic. For identity workloads, it is a critical boundary because a request fetch path without outbound restrictions can be turned into a proxy for internal access, credential leakage, or data exfiltration.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.

What's in the full analysis

Hadrian's full vulnerability alert covers the operational detail this post intentionally leaves for the source:

• Request patterns and exploitation conditions that trigger the SSRF path in affected Next.js deployments
• Practical validation steps for determining whether internal resources are reachable from the web tier
• Remediation guidance for application owners who need to harden WebSocket handling and egress behaviour
• Triage considerations for teams investigating whether internal services or metadata endpoints were exposed

👉 Hadrian's full post covers the exploitation path, exposure scope, and remediation considerations in more detail

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the broader security programmes they operate every day.