SSRF in self-hosted Next.js built-in Node.js server via WebSocket upgrade requests

Repository is a standalone proof-of-concept and lab environment for CVE-2026-44578, a pre-authentication SSRF in self-hosted Next.js WebSocket upgrade handling. The main exploit logic is in `exploit/poc.py`, which opens a raw TCP/TLS socket to a target Next.js server and sends a crafted HTTP/1.1 GET request using an absolute-form URI plus WebSocket upgrade headers. This abuses the vulnerable upgrade handler so Next.js proxies the request server-side to localhost:80 with an attacker-controlled path. The exploit supports a default IMDS probe, custom SSRF URL input, and a 7-test suite that validates metadata listing, instance ID extraction, IAM role discovery, IAM credential theft, user-data retrieval, IAM info access, and account ID extraction. `exploit/curl_poc.sh` provides a minimal bash/netcat variant, and `exploit/test_vuln_vs_fixed.sh` compares vulnerable vs patched instances. The repository also includes a full Docker lab under `lab/` with two Next.js containers: vulnerable 15.5.15 exposed on localhost:3000 and patched 15.5.16 exposed on localhost:3001. A fake IMDSv1 service (`lab/imds-mock/imds_server.py`) listens on port 80 and exposes realistic metadata endpoints such as `/latest/meta-data/`, `/latest/meta-data/iam/security-credentials/NextjsAppRole`, and `/latest/user-data`. An additional internal service mock (`lab/internal-api/internal_server.py`) exposes `/admin`, `/health`, and `/secret`, demonstrating how arbitrary internal HTTP services could be reached. Docker Compose uses shared network namespaces for the IMDS sidecars so that localhost:80 from the Next.js container resolves to the fake metadata service, accurately modeling the intended SSRF condition. Overall purpose: demonstrate and validate exploitation of Next.js self-hosted versions 13.4.13–15.5.15 and 16.0.0–16.2.4, show the security impact against cloud metadata and internal services, and confirm that patched versions 15.5.16 and 16.2.5 block the attack. This is a real exploit repository, not merely documentation or detection logic.

This repository is a small Python proof-of-concept for CVE-2026-44578, described as a Next.js WebSocket SSRF issue. It contains only two files: a README with usage examples and remediation guidance, and a single executable script, poc.py, which is the main entry point. The script supports two modes. First, a detection mode sends an HTTP GET request to the target root path with Upgrade: websocket and Connection: Upgrade headers and treats an HTTP 101 response as evidence of vulnerability. Second, an exploitation mode opens a WebSocket connection to ws://<target>/ while overriding the Host header with an attacker-chosen internal host:port, thereby attempting to coerce the vulnerable server into connecting to internal resources. If a payload is supplied, the script sends raw text to the tunneled service and prints one response. The README demonstrates likely use cases such as querying Redis with INFO and accessing AWS instance metadata at 169.254.169.254. Overall, this is a straightforward operational PoC for unauthenticated SSRF and internal service access, not a framework module and not merely a detector.

Repository contains a single Python exploit tool (`nextssrf.py`) plus a README. The script is a standalone Python 3 utility, not tied to a major exploit framework, and implements both vulnerability scanning and active exploitation for CVE-2026-44578, an SSRF in the Next.js WebSocket upgrade handler. The exploit works by opening a raw TCP/TLS connection to the target and sending an HTTP request whose request-target is an absolute URL, combined with `Connection: Upgrade` and `Upgrade: websocket`, causing vulnerable self-hosted Next.js instances to proxy a GET request to an attacker-chosen destination. Main capabilities visible from the code and documentation: (1) single-target and multithreaded bulk scanning; (2) SSRF confirmation by reading proxied response bodies; (3) Next.js fingerprinting via response markers such as `/_next/static` and `/_next/chunks`; (4) interactive shell mode; (5) auto cloud detection; (6) cloud-focused exploitation paths, especially AWS metadata enumeration and IAM credential extraction, with Azure support also referenced; (7) custom SSRF destination support for internal hosts/paths; and (8) JSON/JSONL result export. The code uses only Python standard library modules such as `socket`, `ssl`, `urllib`, `threading`, and `json`. Repository structure is minimal: `README.md` documents the vulnerability, affected versions, usage examples, limitations, and expected outcomes; `nextssrf.py` is the operational entry point. Based on the available code and README, this is a real exploit utility rather than a detector-only script. It is operational but not obviously framework-weaponized: payloads are built into the script and oriented around SSRF and metadata extraction rather than arbitrary post-exploitation.