Topic starter
02/08/2026 11:36 am
TL;DR: A Next.js WebSocket SSRF flaw can let unauthenticated attackers reach internal resources, expanding exposure from a public endpoint into trusted network paths, according to Hadrian. The issue reinforces that network trust boundaries and access controls must be validated at runtime, not assumed from service location.
Editorial analysis by NHI Mgmt Group, based on content published by Hadrian: “Next.js WebSocket SSRF: Unauthenticated Access to Internal Resources: CVE-2026-44578”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The core risk is unauthenticated server-side request forgery through a WebSocket path that can expose internal resources.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:50 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Next.js WebSocket SSRF exposes internal resources without auth