Next.js WebSocket Upgrade SSRF

This is a self-contained Docker laboratory and functional Python PoC for CVE-2026-44578, an unauthenticated SSRF in affected self-hosted Next.js Node-server WebSocket upgrade handling. `exploit/exploit.py` opens a raw socket to a configurable target (default `127.0.0.1:3000`) and sends a malformed absolute URI (`http:///...`) with WebSocket Upgrade headers. The intended behavior is to cause Next.js to proxy the retained path to localhost port 80, allowing read-only retrieval of internal HTTP resources. The PoC makes seven predefined probes for metadata, IAM credentials, user-data, an identity document, and internal configuration; it masks flag-shaped data only in its terminal output. The repository has three main components: the Python exploit under `exploit/`; a Python fake IMDSv1 server under `imds-mock/`, which serves navigable AWS-like metadata and deliberately seeded secret artifacts; and a minimal Nimbus Analytics Next.js application under `nextjs-app/`. `docker-compose.yml` publishes the vulnerable Next.js application on port 3000 and runs the IMDS mock in the same network namespace, making the mock service reachable only as localhost:80 from the vulnerable process. The JavaScript application is otherwise a static demonstration site with a health endpoint. The exploit is not framework-based and is a valid operational lab PoC, not merely a detection utility.

This repository is a self-contained lab and proof-of-concept for CVE-2026-44578, a Next.js WebSocket upgrade handler SSRF issue. The main exploit is exploit/exploit.py, a Python script that deliberately avoids high-level HTTP libraries and instead uses a raw TCP socket to send an HTTP/1.1 request with an absolute-form request target such as 'GET http://internal-svc/admin HTTP/1.1'. The request also includes 'Connection: Upgrade' and 'Upgrade: websocket', aiming to trigger vulnerable proxying behavior in Next.js. The exploit is interactive only in the sense of command-line arguments; it does not deliver code execution, but it does retrieve internal HTTP responses through the vulnerable server. Repository structure: docker-compose.yml defines a two-container lab. 'nextjs-vuln' exposes port 3000 publicly and is attached to both a public and isolated internal Docker network. 'internal-svc' is attached only to the internal network and exposes no host port, making it unreachable directly from the attacker. The nextjs-app directory contains a minimal Next.js application pinned to version 15.5.0, explicitly described as vulnerable. The internal-svc directory contains a Python HTTP server that simulates sensitive internal resources. Exploit capabilities: The exploit can target arbitrary SSRF hosts and paths via --ssrf-host and --ssrf-path. By default it requests /admin on internal-svc, but usage examples show access to AWS-style metadata paths and internal configuration paths. The script prints the raw request, connects to the target Next.js server, sends the crafted payload, and displays the returned response. It also heuristically flags success if the response contains markers such as 'FLAG', 'AccessKeyId', or 'SecretAccessKey'. Notable targets and leaked data in the lab: internal-svc/server.py simulates internal-only endpoints including /admin, /latest/meta-data/, /latest/meta-data/iam/security-credentials/lab-ssrf-role, and /internal/config. These return mock secrets such as database credentials, API keys, JWT secrets, and AWS-style credentials. This confirms the repository’s purpose is exploitation and demonstration of SSRF impact rather than detection. Overall maturity is POC: the exploit is functional and configurable for SSRF destinations, but it is a standalone demonstration script rather than a broader weaponized framework module.

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.