CVE-2026-78329

ملخص

ثغرة تحقق غير سليم من صحة الإدخال في مكوّن Apache Camel Undertow. تؤثر هذه المشكلة على Apache Camel: من 4.11.0 حتى ما قبل 4.14.9، ومن 4.15.0 حتى ما قبل 4.18.4، ومن 4.19.0 حتى ما قبل 4.22.0. كان UndertowEndpoint يعيّن افتراضيًا حقل headerFilterStrategy إلى HttpHeaderFilterStrategy الأساسي ويدفع ذلك الكائن إلى UndertowHttpBinding الذي ينشئه بشكل كسول (lazily)، مستبدلاً بذلك UndertowHeaderFilterStrategy الذي يثبّته DefaultUndertowHttpBinding في مُنشئه الخاص. ولذلك، ما لم توفّر بيئة النشر ربطًا مخصصًا أو headerFilterStrategy صريحًا، لم تكن التصفية الخاصة بـ undertow تُنفَّذ أبدًا على المسارات المكوّنة عبر نقطة النهاية: كان كائن الاستراتيجية يُنشأ ثم يُستبدل فورًا قبل أن يُستشار. والنتيجة هي أن بادئة الرأس القديمة websocket. Exchange-header لم تكن تُصفَّى عند حدود نقل undertow في أيٍّ من الاتجاهين، لذا كان مستهلك HTTP من نوع undertow يعيّن الرؤوس الواردة عبر الشبكة (inbound wire headers) بهذه الصيغة على Exchange، حيث يقرؤها منتج WebSocket من نوع undertow كتوجيهات توزيع، ويمكن دفعه للتسليم إلى نظير آخر غير النظير الذي اختاره المسار؛ كما أن أسماء الرؤوس التي لا يقبلها undertow نفسه كانت تُعيَّن على Exchange بدلًا من تخطّيها. لم يتأثر مستهلكو Rest DSL أبدًا، لأن UndertowComponent يعيّن UndertowRestHeaderFilterStrategy بشكل صريح، وهو ما يوسّع استراتيجية undertow. هذه ليست انتكاسةً لـ CVE-2025-30177: فـ HttpHeaderFilterStrategy الأساسي يُهيئ بنفسه مرشح بادئة Camel للرؤوس الواردة، لذا فإن الحماية التي أدخلتها تلك النشرة الأمنية استمرت في العمل عبر الفئة الأساسية ولم تُفقَد أبدًا. ما فعله هذا التغيير هو ترك استراتيجية undertow يتيمة على مسار نقطة النهاية، بحيث إن تصحيحين لاحقين كُتبا فيها — أحدهما يتخطى أسماء الرؤوس التي يرفضها undertow، والآخر يصفّي بادئة websocket. القديمة في كلا الاتجاهين — طُبّقا على فئة لم تعد نقطة النهاية تستخدمها، ولم يكن لهما أي أثر في الإصدارات التي صدرت بها. يُنصح المستخدمون بالترقية إلى الإصدار 4.22.0 الذي يصلح المشكلة. وإذا كان المستخدمون على مسار إصدارات 4.14.x LTS، فيُقترح عليهم الترقية إلى 4.14.9. وإذا كان المستخدمون على مسار إصدارات 4.18.x، فيُقترح عليهم الترقية إلى 4.18.4. أما بيئات النشر التي لا يمكنها الترقية فورًا، فهيّئ الاستراتيجية بشكل صريح بدلًا من الاعتماد على الافتراضية، على سبيل المثال عبر ربط UndertowHeaderFilterStrategy في السجل (registry) والإشارة إليه على نقطة النهاية مثل undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy، بالإضافة إلى إزالة رؤوس التوزيع عند حدود الثقة باستخدام removeHeaders(“websocket.*”). لاحظ قيدًا متبقّيًا لا تزيله الترقية: مكوّن undertow يُبقي قيم websocket. عمدًا كجزء من عقد واجهته البرمجية (API) المرئي خارجيًا، ويقرؤها UndertowProducer عبر in.getHeader، الذي لا يستشير HeaderFilterStrategy إطلاقًا. لذلك فإن التصفية المستعادة لا تمثل أكثر من دفاع في العمق عند حدود نقل undertow. والمسار الذي ينقل رسالة غير موثوقة من مستهلك غير undertow إلى منتج undertow لا يحميه هذا الإصلاح، ويجب عليه إزالة تلك الرؤوس بنفسه.