Notifications
Clear all
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.
NHIMG editorial — based on content published by Hadrian: Next.js WebSocket SSRF and unauthenticated access to internal resources
Questions worth separating out
Q: What breaks when a public application can make unauthenticated internal requests?
A: The main failure is that external input starts inheriting internal trust.
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.
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.
Practitioner guidance
- Constrain outbound destinations for web workloads Allow only the internal and external endpoints that the application truly needs.
- Protect metadata and internal APIs with explicit auth Require authentication on internal services even when they are not internet-facing.
- Instrument WebSocket traffic for anomalous relay patterns Log destination hosts, unusual upgrade requests, and repeated internal lookup attempts from the same public endpoint.
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
👉 Read Hadrian's vulnerability alert on Next.js WebSocket SSRF and internal resource exposure →
Next.js WebSocket SSRF: what it means for internal access controls?
Explore further
02/08/2026 12:50 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Next.js WebSocket SSRF exposes internal resources without auth
