CVE-2026-90678 in HAProxy
الملخص
بحسب VulDB • 13/09/2026
تم اكتشاف مشكلة في HAProxy الإصدارات من 3.3.0 حتى 3.4.4، وفي الإصدارات التجريبية (dev) من 3.5-dev1 إلى 3.5-dev5. تتطلب عملية الاستغلال واجهة أمامية تدعم HTTP/3: يجب أن يكون HAProxy مُبنىً بدعم بروتوكول QUIC ومُهيأً باستخدام مستمع ارتباط QUIC، ويجب أن تصل حركة المرور المتضررة إلى الخادم الخلفي (backend) عبر HTTP/1.1 باستخدام ترميز النقل المقطّع (chunked transfer coding) على اتصال معاد استخدامه. في ظل هذه الظروف، عندما لا يحمل طلب HTTP/3 رأس Content-Length، فإن مكوّن تعدد الإرسال الخاص بـ HTTP/3 ي credited الطول المُعلن في رأس إطار DATA إلى تقدير الحمولة المدخلة المعروفة لنهاية التدفق (stream endpoint) في اللحظة التي يتم فيها فك تشفير رأس الإطار، وقبل استلام الحمولة الفعلية، ويتم إصدار هذا الطول المُعلن حرفياً كحجم القطعة (chunk size) الخاص بـ HTTP/1.1. يؤدي عميل عن بُعد غير مُصادق عليه يعلن حمولة أكبر مما يوصله ثم ينهي التدفق إلى إعلان HAProxy لقطعة أكبر من عدد البايتات التي يكتبها، وإرجاع الاتصال إلى مجموعة الحالة الخاملة في حالة عدم تزامن (desynchronized state). النتيجة هي احتمال حدوث تنميط طلبات HTTP على الاتصالات المعاد استخدامها مع الخادم الخلفي: يمكن للمهاجم وضع طلب يتجاوز قاعدة واجهة أمامية مثل حظر http-request القائم على المسار، بحيث لا يراها تحليل HTTP الخاص بـ HAProxy أبداً، ويمكنه أن يجعل طلبات العملاء المتزامنين، بما في ذلك أسطر الطلبات ورؤوس Authorization، تُستهلك كجسم طلب المهاجم وتُفقد. الاستغلال ليس حتمياً؛ فهو يعتمد على سباق مع جدولة اتصالات الخادم الخلفي (backend connection pooling)، وينجح في أغلبية المحاولات ولكن ليس جميعها أثناء الاختبار، ويمكن إعادة المحاولة بحرية. أُدخلت هذه الآلية في الإصدار 3.3-dev10؛ والإصدارات 3.2.x وما قبلها غير متأثرة.
If you want to get best quality of vulnerability data, you may have to visit VulDB.