Topic starter
02/08/2026 11:36 am
TL;DR: Unauthenticated access to internal resources can result from a Next.js WebSocket SSRF flaw, according to Hadrian. WebSocket routing then turns private network placement into a weak control, so internal services need service-level authentication and explicit destination checks.
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: 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.
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.
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.
Glossary terms: Server-Side Request Forgery, Internal Resource Exposure, Service-To-Service Authentication, WebSocket Request Routing
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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