ثغرة XRING غير المصححة في XQUIC تُسقط خوادم HTTP/3 عن بعد بلا جهد

مقدمة تحليلية

في 8 يوليو 2026، كشف الباحث Sébastien Féry من شركة FoxIO عن ثغرة أمنية حرجة وغير مصححة في مكتبة XQUIC مفتوحة المصدر من Alibaba، أطلق عليها اسم XRING. تسمح هذه الثغرة لأي عميل بعيد بإسقاط خادم HTTP/3 باستخدام 260 بايت فقط من حركة مرور QPACK العادية. لا يتطلب الهجوم تسجيل دخول أو حزم بيانات مشوهة، مما يجعله تهديدًا مباشرًا وشديد الخطورة. الثغرة تؤثر على جميع إصدارات XQUIC حتى v1.9.4، وهو أحدث إصدار، ولا يوجد تصحيح رسمي متاح أو رقم CVE مخصص لها حتى 10 يوليو. هذا الوضع يضع أي خادم يستخدم XQUIC ويخدم بروتوكول HTTP/3 بإعدادات QPACK الافتراضية تحت خطر تعطيل الخدمة بشكل كامل، بما في ذلك خوادم Tengine من Alibaba التي تدعم سحابة الشركة وشبكة توصيل المحتوى لمواقع مثل Taobao وAlipay.

التحليل التقني

تكمن مشكلة XRING (ثغرة أمنية تسمح بتعطيل خدمة خوادم HTTP/3 عن بعد عن طريق استغلال خطأ في معالجة QPACK) في كيفية تطبيق XQUIC (مكتبة Alibaba مفتوحة المصدر التي تطبق بروتوكولات QUIC وHTTP/3) لآلية ضغط رؤوس HTTP/3 المعروفة باسم QPACK (تقنية ضغط الرؤوس لبروتوكول HTTP/3 تهدف إلى تقليل حجم البيانات المرسلة عبر الشبكة). تستخدم QPACK جدولًا ديناميكيًا مشتركًا، يديره العميل، لتخزين الرؤوس المستخدمة بشكل متكرر وتجنب إرسالها مرارًا وتكرارًا. تقوم XQUIC بتخزين بايتات هذا الجدول في ring buffer (ذاكرة مؤقتة حلقية، وهي كتلة ذاكرة ذات حجم ثابت تُخزن فيها البيانات بشكل دائري، حيث تلتف الكتابة من النهاية إلى البداية بعد الامتلاء).

عندما يطلب العميل زيادة حجم هذا الجدول، تقوم XQUIC بتخصيص ذاكرة مؤقتة جديدة أكبر ونسخ البيانات الموجودة من الذاكرة القديمة إليها. هنا يظهر الخطأ الحسابي الفادح. توجد أربع حالات محتملة لعملية النسخ هذه، بناءً على ما إذا كانت البيانات تلتف في الذاكرة المؤقتة القديمة أو الجديدة أو كليهما أو لا شيء منهما. في إحدى هذه الحالات، تحديدًا عندما تلتف البيانات في الذاكرة المؤقتة القديمة ولكن ليس في الذاكرة الجديدة، تقوم XQUIC بحساب حجم البيانات المتبقية "الذيلية" مقارنةً بسعة الذاكرة المؤقتة الجديدة الأكبر بدلاً من مقارنتها بسعة الذاكرة القديمة الأصغر. هذا الخطأ يؤدي إلى تضخيم كبير في العدد المحسوب.

• إذا طُلب تكبير جدول بحجم 64 بايت، مع وجود مؤشر الكتابة بالقرب من النهاية، وإعادة تحجيمه إلى 65 بايت، فإن XQUIC ستحسب أن هناك 70 بايتًا من البيانات الذيلية يجب نقلها، بينما الحجم الفعلي لا يتجاوز 6 بايتات.

هذا العدد الخاطئ يُمرر بعد ذلك إلى دالة نسخ الذاكرة. يتم حساب طول النسخ بطرح هذا العدد المبالغ فيه من قيمة أخرى أصغر. بما أن هذا الطول يُعالج كمتغير من نوع `unsigned size_t`، فإنه يحدث له تجاوز للحد الأدنى (integer underflow) ليلتف إلى رقم قريب من القيمة القصوى الممكنة. هذا يؤدي بدوره إلى محاولة عملية النسخ الكتابة خارج حدود الذاكرة المخصصة.

في بيئة اختبار FoxIO التي تستخدم إصدارًا من Ubuntu 26.04، تمكنت ميزة `_FORTIFY_SOURCE=2` من اكتشاف الطول الخاطئ وأنهت العملية، مما أدى إلى تعطل (crash) الخادم. بدون هذا الفحص، ستستمر عملية النسخ في الكتابة خارج الحدود المخصصة، من الذاكرة المؤقتة القديمة مروراً بنهاية الذاكرة الجديدة. أظهر Féry تعطلًا ولم يختبر ما إذا كان هذا الفساد يمكن استغلاله بشكل أعمق لتنفيذ تعليمات برمجية. الجدير بالذكر أن القيم المستخدمة في الهجوم لا تنتهك قواعد QPACK على الإطلاق؛ الحمولة تطلب أحجامًا عادية (64 ثم 65 بايتًا) بينما XQUIC تعلن عن حد افتراضي لجدول ديناميكي بحجم 16 كيلوبايت. وقد أكدت FoxIO أن هذا الخطأ كان موجودًا في XQUIC منذ إطلاقها العلني الأول في يناير 2022، مع توفر إثبات للمفهوم (PoC) علنيًا.

السياق وتأثير السوق

بما أن XQUIC هي مكتبة مفتوحة المصدر، فإن مخاطر XRING لا تقتصر على Alibaba وحدها. أي خادم يدمجها ويقدم خدمة HTTP/3 مع إعدادات QPACK الافتراضية معرض للخطر. يشمل ذلك Tengine، وهو خادم ويب يعتمد على Nginx وتطوره Alibaba، والذي تستخدمه الشركة لدعم بنيتها التحتية السحابية وشبكة توصيل المحتوى لمواقع رئيسية مثل Taobao وAlipay. هذا يعني أن نطاق التأثير المحتمل واسع.

تُعد XRING أحدث إضافة إلى سلسلة من الثغرات التي تسبب تعطلات عن بعد في مكدسات HTTP/2 وHTTP/3:

• XRING في XQUIC مقابل CVE-2026-42530 في NGINX HTTP/3: قبل ثلاثة أسابيع فقط، كشف تقرير عن ثغرة "use-after-free" في وحدة HTTP/3 الخاصة بـ NGINX (CVE-2026-42530)، والتي يمكن لعميل بعيد وغير مصادق عليه الوصول إليها عبر نفس "تيار المرمز" لـ QPACK الذي تستغله XRING. على الرغم من أن الثغرة مختلفة الفئة، إلا أنها تشير إلى نفس سطح الهجوم الحساس في ضغط الرؤوس.
• XRING في XQUIC مقابل "قنبلة HTTP/2" لـ Calif: في يونيو، تسببت ثغرة "HTTP/2 Bomb" لـ Calif في هجمات رفض الخدمة عن بعد ضد Nginx وApache وIIS وEnvoy. استغلت هذه الثغرة HPACK، وهي آلية ضغط الرؤوس لـ HTTP/2 وسلف QPACK. الاختلاف الجوهري هو أن XRING تستهدف البروتوكول الأحدث، HTTP/3، عبر QPACK.
• XRING في XQUIC مقابل ثغرات تعطل QUIC في HAProxy: في فبراير، قامت HAProxy بتصحيح ثغرتين تسببان تعطل QUIC. إحداهما كانت "integer underflow" أثناء التحقق من الرموز، وهو نفس نوع الخطأ الأساسي وراء XRING. لكن الفارق الحاسم هو أن ثغرات HAProxy تطلبت حزمة بيانات مشوهة، بينما XRING لا تحتاج لأي حزم مشوهة، بل مدخلات قانونية تمامًا. هذا يؤكد على مدى خطورة XRING: مدخلات قانونية تمامًا، خطأ حسابي واحد، وخادم معطل.

الأطراف الخاسرة واضحة: Alibaba التي تجاهلت الإبلاغات، ومشغلو الخوادم الذين يستخدمون XQUIC. المخاطر تشمل توقف الخدمة وتدهور سمعة العلامة التجارية. أما الرابحون فهم باحثو الأمن الذين يقومون بعملهم بكشف هذه العيوب. للتخفيف من تأثير الثغرة حتى يتم توفير إصلاح، يمكن للمشغلين إما تعيين `SETTINGS_QPACK_MAX_TABLE_CAPACITY` إلى 0، مما يؤدي إلى إيقاف تشغيل جدول QPACK الديناميكي، أو إسقاط دعم HTTP/3 بالكامل. كلتا الطريقتين تمثلان حلولًا مؤقتة تأتي على حساب الأداء أو الوظائف.

رؤية Glitch4Techs

تقاعس Alibaba عن معالجة ثغرة XRING ليس مجرد إهمال، بل هو تقصير أمني خطير وغير مقبول على الإطلاق. بعد خمس محاولات إفصاح من باحث أمني مرموق منذ أبريل 2026، فإن تجاهل الاستجابة لا يدل إلا على لامبالاة مؤسسية تجاه أمن منتجاتها ومستخدميها. هذا السلوك لا يقوض الثقة في Alibaba كشركة رائدة في مجال التكنولوجيا فحسب، بل يضع عددًا لا يحصى من الخوادم والبنى التحتية تحت خطر مباشر لهجمات رفض الخدمة التي لا تتطلب أي مهارة خاصة. الاعتماد على ميزات الحماية في نظام التشغيل مثل `_FORTIFY_SOURCE=2` كخط دفاع أخير ليس بديلاً عن معالجة جذر المشكلة. المجتمع التقني يستحق الشفافية والاستجابة السريعة عند مواجهة عيوب أمنية بهذا الحجم. يجب على Alibaba أن تقدم فورًا إصلاحًا لهذه الثغرة الحرجة، وتخصيص رقم CVE، وتقديم تفسير مقنع لتقاعسها المذهل. هذه الحادثة تذكرنا بحقيقة صارخة: حتى المكونات الأساسية مفتوحة المصدر يمكن أن تصبح نقاط ضعف كارثية إذا لم يتحمل المطورون الرئيسيون مسؤولياتهم الأمنية.