CVE-2026-69243 — تهريب الطلبات في aiohttp (CWE-444)

تهريب الطلبات عبر ترقية WebSocket مرفوضة في aiohttp < 3.14.2. عندما يمرر خادم وكيل عكسي ترويسات Connection: Upgrade + Upgrade: websocket، يتجاهل محلل aiohttp الضعيف نص الطلب ويفسر البايتات الزائدة كطلب مبطن (pipelined) — متجاوزًا ضوابط الوصول الطرفية.

تم الإصلاح في aiohttp 3.14.2 (commit 6ae358f).

المؤلف: João Victor Botelho (JV Botelho) — https://glitchedcat.com

تشغيل خلال 60 ثانية

انسخ والصق نسخة بايثون (بدون أي تبعيات، المكتبة القياسية فقط):

curl -O https://raw.githubusercontent.com/JVBotelho/cve-2026-69243-poc-aiohttp-smuggling/main/poc.py
python3 poc.py <proxy-host> <proxy-port> <backend-host>

أو اطبع نسخة Rust (بدون تبعيات، std فقط):

git clone https://github.com/JVBotelho/cve-2026-69243-poc-aiohttp-smuggling
cd cve-2026-69243-poc-aiohttp-smuggling/poc
cargo build --release
./target/release/cve-2026-69243-poc <proxy-host> <proxy-port> <backend-host>

سيتم نشر الملفات الثنائية المجمعة مسبقًا إلى Releases عبر سير عمل الإصدارات.

كلا النسختين تنتجان حمولات مطابقة بايتًا ببايت (يضمنها اختبار تكافؤ في CI). إذا كان المختبر يعمل:

python3 poc.py nginx-upgrade 80 backend-vuln

الإخراج المتوقع: استجابة HTTP واحدة (WebSocket upgrade rejected). ثم تحقق:

# Backend processed 2 requests (/ws + smuggled /admin):
docker logs backend-vuln | grep -c '"path".*"/admin"'

# Nginx only logged 1 request (the /ws):
docker exec nginx-upgrade cat /logs/nginx-upgrade.access.log | grep -c '/admin'

أن عدد طلبات الخادم الخلفي > 0 وعدد Nginx = 0 يعني تأكيد انقسام CWE-444. يرسل هذا الـ PoC مقطع TCP واحدًا — حيث يكون النص هو الطلب المُهرب؛ تعامله Nginx كنص للطلب بينما تعامله aiohttp كطلب ثانٍ.

ما الذي يثبته هذا

• ارتباك المحلل: يُرجع _http_parser.pyx في aiohttp 3.14.1 القيمة 2 (تخطي النص) عند اكتشاف الترقية قبل استهلاك النص (سطر ~863). تبقى بايتات النص في _message_tail وتُعاد إلى المحلل في web_protocol.py finish_response (سطر ~771).
• انقسام CWE-444: ترى الواجهة الأمامية طلبًا واحدًا مع نص؛ بينما يرى الخادم الخلفي طلبين مبطنين. عدم تطابق في عدد الطلبات بالسجلات.
• تجاوز ضوابط الوصول: عندما يحتوي Nginx على location /admin { deny all; }، يظل الطلب المُهرب /admin يصل إلى الخادم الخلفي لأن قرارات توجيه Nginx تُتخذ بناءً على الطلب الخارجي فقط.
• لا يوجد إصلاح على مستوى المعالج: يُرجع await request.read() صفر بايت في طلبات الترقية في 3.14.1 — يُحجب النص تحت طبقة المعالج. طبّق التصحيح، أو أزل ترويسات الترقية عند الوكيل على المسارات التي يجب ألا تبدّل البروتوكولات.

المختبر الكامل

git clone https://github.com/JVBotelho/cve-2026-69243-poc-aiohttp-smuggling
cd cve-2026-69243-poc-aiohttp-smuggling
docker compose up -d

# Run the PoC:
docker compose run --rm --entrypoint /app/poc attacker nginx-upgrade 80 backend-vuln

الخدمات:

نتائج المراحل 1-3 كاملة في findings/.

القيود (بصراحة)

• يجب أن يمرر الوكيل ترويسات الترقية. إعدادات Nginx التي ترسل Connection: close إلى الخادم الخلفي أو تزيل ترويسات Connection/Upgrade ليست قابلة للاستغلال. الإعداد الذي يكشف الانقسام هو مقتطف map القياسي لـ WebSocket من توثيق Nginx الخاص بالوكالة.
• يبتلع الوكيل الاستجابة المُهربة. في سلسلة Nginx الموضحة، يتلقى المهاجم استجابة /ws الخارجية فقط. دليل التهريب موجود في سجلات الخادم الخلفي وليس في استجابة المهاجم — بدائية عمياء أحادية الاتجاه في هذا الطوبولوجيا. لم يتم اختبار طوبولوجيات وكيل أخرى.
• تأطير chunked خاص بـ CL في الواقع. مباشرة ضد aiohttp، لا يُهرب Transfer-Encoding: chunked — يصطدم سطر حجم القطعة الخام (مثل 3e) بالمحلل كطريقة غير صالحة وينقطع الاتصال. عبر Nginx يعمل، لكن عبر التطبيع: يزيل Nginx التقطيع من النص ويعيد توجيه Content-Length مُصنّع، لذا يُستغل الخادم الخلفي عبر مسار CL نفسه. تُظهر علامة --chunked مسار الوكيل.
• يتطلب نقطة نهاية ترفض ترقيات WebSocket. يجب أن يُرجع المعالج استجابة غير WebSocketResponse. معظم التطبيقات التي لا تستخدم WebSockets على مسار معين سترفض افتراضيًا (يرجع الإطار 404 أو ينتقل إلى المعالج التالي).

الملفات

poc/                       # Rust cargo project
├── Cargo.toml
├── src/main.rs            # CLI binary
├── src/lib.rs             # Library + unit tests
├── tests/parity.rs        # Cross-language payload parity test
└── fuzz/                  # cargo-fuzz targets
poc.py                     # Python PoC (copy-paste from blog)
attacker/ backend/ frontend/   # Docker lab services
docker-compose.yml         # 7-service lab
findings/                  # Research notes (Phase 1-3)
.github/workflows/
├── ci.yml                 # Build, test, clippy, parity, integration, fuzz
└── release.yml            # Cross-compile + GitHub Release

الاكتشاف

راجع findings/fase3-deteccao.md للتحليل الكامل. ملخص، مع التحذيرات المهمة في بيئة الإنتاج:

1. عدم تطابق عدد الطلبات (الخادم الخلفي > الواجهة الأمامية) على نفس الاتصال. لاحظ أن الخادم الخلفي يسجل عنوان IP الخاص بالوكيل وليس عنوان العميل — يتطلب الربط تطبيع X-Forwarded-For/بروتوكول الوكيل، أو تسجيل معرّف اتصال المنبع + تسلسل الطلبات لكل اتصال. عنوان IP للعميل + النافذة الزمنية وحدها ضعيفة (NAT، keep-alive، التزامن).
2. طلب في الخادم الخلفي بدون مقابل في الواجهة الأمامية: مسار مقيّد في سجل الخادم الخلفي بدون إدخال مقابل في سجل الوصول للواجهة الأمامية. صفّ الشبكات الفرعية الداخلية (فحوصات الصحة التي تتجاوز الوكيل تُنتج إيجابيات كاذبة).
3. رفض الترقية + مسار مختلف من نفس العميل خلال ~100 مللي ثانية. ثقة متوسطة — يُنتج خط الأنابيب (pipelining) الشرعي فترات زمنية مماثلة؛ لا يسجل مسجل المختبر منفذ/معرّف اتصال الطرف البعيد، لذا فإن "عدم وجود مصافحة TCP جديدة" ليس شيئًا تُظهره هذه البيانات.
4. برمجيات وسيطة لحجب النص (content_length مقابل البايتات من request.read()): تعمل على 3.14.1 وتصمت على 3.14.2. تكشف ولا تخفف. حدد نطاقها (مسارات الترقية المحتملة، النصوص الصغيرة، الحالات غير 101) — النسخة الساذجة تخزن كل نص في الذاكرة.
5. قياس reqlen عند الحافة أعلى من خط الأساس للترويسات على نقاط نهاية WebSocket — ثقة منخفضة وحدها (الكوكيز/JWT/ترويسات التتبع صاخبة)، لكنها إشارة الحافة الوحيدة عندما لا يرسل العميل Content-Length (دخول chunked).