Next.js WebSocket Upgrade SSRF in self-hosted Node.js server

Repository is a small standalone Python exploit project with 3 files: a GPL license, a detailed README, and one main executable script `nextssrf.py`. The script is the sole code artifact and acts as both scanner and exploit for CVE-2026-44578, an unauthenticated SSRF in self-hosted Next.js WebSocket upgrade handling. Core exploit logic is implemented in the `ssrf()` function, which manually builds and sends a raw HTTP request over a socket. The request uses an absolute-form URI in the request line together with `Connection: Upgrade` and `Upgrade: websocket`, matching the vulnerability described in the README. The script supports both HTTP and HTTPS targets via direct sockets and permissive TLS settings. Repository purpose and structure: - `nextssrf.py`: main scanner/exploit tool with CLI, raw socket exploit delivery, target parsing, Next.js fingerprinting, version checks, multithreaded scanning, interactive shell, auto cloud detection, and cloud-specific exploitation helpers. - `README.md`: operational documentation, affected versions, exploitation mechanism, usage examples, pipeline examples, interactive shell examples, and defensive detection notes. - `LICENSE`: licensing text only. Main capabilities observed from the code and documentation: - Single-target and bulk scanning (`-t`, `--pipe`, `-f`, threaded workers). - Next.js fingerprinting via response markers such as `/_next/static` and `/_next/chunks`. - Vulnerable version handling for Next.js 13.4.13-15.5.15 and 16.0.0-16.2.4. - SSRF confirmation by issuing crafted WebSocket Upgrade requests to attacker-selected absolute URLs. - Interactive exploitation shell for manual follow-on requests. - Auto cloud detection and cloud-focused exploitation workflows. - AWS exploitation chain aimed at metadata enumeration and IAM credential extraction. - Azure exploitation support is referenced in the code paths and README. - Output saving in JSON/JSONL and exit codes indicating clean, vulnerable, or SSRF-confirmed states. The exploit is not merely a detector: it contains active exploitation functionality and post-confirmation workflows for cloud metadata access. However, it is still a standalone PoC/operational script rather than a framework-integrated or highly modular weaponized platform, so `OPERATIONAL` is the best maturity fit.

Repository contains a single Python exploit script and a README. The main file, cvesiber2026.py, is a standalone Python 3 tool implementing an SSRF exploit for CVE-2026-44578 in self-hosted Next.js WebSocket upgrade handling. It builds a raw HTTP request with an absolute-form URL in the request line and WebSocket upgrade headers, then sends it directly over a socket (optionally TLS-wrapped) to the target host. The intended effect is to make the vulnerable Next.js server proxy a GET request to an attacker-controlled internal destination. Capabilities visible from the script and README include: single-target scanning, piped/bulk scanning with threads, optional file-based target input, interactive exploitation mode, auto mode, custom SSRF destination selection, cloud-provider detection, and cloud-specific exploitation helpers. The README and surviving code fragments indicate dedicated AWS and Azure routines, with AWS support extending to metadata enumeration, IAM role discovery, and credential extraction when metadata is exposed. The tool also supports saving results as JSON or JSONL and uses exit codes to distinguish clean, vulnerable, and SSRF-confirmed states. The exploit is operational rather than a simple detector because it actively sends the crafted request and is designed to retrieve internal resources. It is not part of a major exploitation framework. The repository structure is minimal: README.md documents the vulnerability, affected versions, usage patterns, and expected outcomes; cvesiber2026.py contains the exploit logic, CLI handling, threading, socket/TLS networking, and result export. The attack surface is primarily web/network, with cloud impact due to metadata-service targeting. Limitations documented by the author are GET-only SSRF, effective targeting of port 80 destinations, incompatibility with AWS IMDSv2 token flow, and likely failure when reverse proxies reject absolute-form URIs.

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.