Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
CVE-2026-33555 — حزمة QUIC واحدة بحجم صفر بايت تكفي لفك مزامنة تجمع الاتصالات الخلفي في HAProxy وتهريب طلبات HTTP عبر مستخدمين غير مرتبطين ببعضهم — حتى المستخدمين على بروتوكول واجهة أمامية مختلف تمامًا. | Kitploit
أدوات/GitHubGitHub/r3verii/cve-2026-33555
تحليل الثغرات الأمنيةالاستغلالاستغلال تطبيقات الويبأمن الويبأمن الشبكاتالأوراق والأبحاث
GitHubr3verii/cve-2026-33555

CVE-2026-33555

حزمة QUIC واحدة بحجم صفر بايت تكفي لفك مزامنة تجمع الاتصالات الخلفي في HAProxy وتهريب طلبات HTTP عبر مستخدمين غير مرتبطين ببعضهم — حتى المستخدمين على بروتوكول واجهة أمامية مختلف تمامًا.

عرض المستودع
2منذ 4 أشهرلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

ثغرة تهريب طلبات HTTP عبر HAProxy H3/QUIC لتجاوز التحقق من جسم طلب FIN المستقل

المقال كاملاً هنا : https://r3verii.github.io/cve/2026/04/14/haproxy-h3-standalone-fin-smuggling.html

الملخص

ثغرة في تنفيذ HAProxy لبروتوكول HTTP/3 تسمح للمهاجم بإرسال طلب HTTP يحمل ترويسة Content-Length لا تطابق الحجم الفعلي للجسم. يقوم HAProxy بإعادة توجيه هذا الطلب المشوّه إلى الخادم الخلفي عبر HTTP/1.1 مع Content-Length المُعلَن ولكن بدون أي بايتات للجسم. عندما يرسل الخادم الخلفي استجابة مبكرة (مثل إعادة توجيه 301) ويقوم بتفريغ الجسم المعلّق من اتصال TCP، فإنه يستهلك بايتات تخص الطلب التالي على ذلك الاتصال — والذي قد يكون صادراً من مستخدم مختلف.

يؤدي هذا إلى تهريب طلبات HTTP بين المستخدمين عبر تجمّع اتصالات الخادم الخلفي في HAProxy.

المتأثر: HAProxy مع دعم QUIC/H3 (). تم اختباره على HAProxy 3.0.18. : (غير افتراضي، لكنه شائع في بيئات الإنتاج)

USE_QUIC=1
الإعداد المطلوب
http-reuse always

إعداد المختبر

Docker Compose مع 3 خدمات:

  • haproxy: واجهة أمامية H3/QUIC (منفذ 10002/udp) + H2/TCP (منفذ 10002/tcp)، مع تجمّع اتصالات الخادم الخلفي (http-reuse always)
  • nginx: nginx 1.27 قياسي مع autoindex on على دليل /photos، و/status يُرجع 200
  • client: حاوية Python مع aioquic

الخطوات

root@kitploit:~
# 1. تشغيل المختبر (بناء HAProxy يستغرق ~10 دقائق في المرة الأولى)
cd poc/
docker compose up -d --build

# 2. تشغيل PoC في الوضع المستمر
docker exec -it poc-client python3 poc.py --target haproxy --port 10002 --interval 3

# 3. من المتصفح، انتقل إلى https://<host>:10002/status
#    (اقبل الشهادة ذاتية التوقيع، واستخدم --ignore-certificate-errors في Chrome)
#    حدّث الصفحة بشكل متكرر. ~50% من الاستجابات ستكون 400 Bad Request.

# 4. أوقف PoC (Ctrl+C). ستعود جميع استجابات المتصفح إلى الوضع الطبيعي (200).

التحقق بطلقة واحدة

root@kitploit:~
docker exec -it poc-client python3 poc.py --target haproxy --port 10002 --once

المخرجات المتوقعة:

root@kitploit:~
[1] إرسال طلب التسميم (H3/QUIC)...
    -> تم استلام 301. اتصال الخادم الخلفي مُجمَّع مع تفريغ جسم معلّق.
[2] الانتظار 0.5 ثانية حتى يقوم HAProxy بتجميع الاتصال...
[3] إرسال طلب الضحية GET /status من اتصال QUIC منفصل...
    -> الاستجابة: HTTP 400

  [!] تم تأكيد التهريب
  [!] حصلت الضحية على 400 على اتصال منفصل بدلاً من 200
  [!] قام الخادم الخلفي بتحليل طلب الضحية كجسم لطلب POST المسموم
تنزيل الأداة