CVE-2026-66908

ملخص

ثغرة مصادقة غير سليمة في مكوّن Apache Camel Platform HTTP Main. تؤثر هذه المشكلة على Apache Camel: من الإصدار 4.8.0 حتى ما قبل 4.22.0. يمكن لخادم HTTP المدمج في camel-main حماية نقاط النهاية الخاصة به باستخدام مصادقة JWT، ويتم تكوين ذلك عبر authenticationEnabled إلى جانب خصائص مخزن مفاتيح JWT. كانت الدالة JWTAuthenticationConfigurer.buildJwtOptions تُرجع قيمة null عندما لا يكون أيٌّ من jwtIssuer أو jwtAudience مُهيَّأً، وكان المتصل يتجاوز بعدها استدعاء JWTAuthOptions.setJWTOptions بالكامل، لذلك كان يتم إنشاء مثيل Vert.x JWTAuth من مخزن المفاتيح وحده. وكانت النتيجة أن الرموز الواردة كانت تُفحص من حيث التوقيع وانتهاء الصلاحية فقط: لم يتم التحقق من الادعاءين iss و aud على الإطلاق. لم يكن هناك ما ينبئ بذلك، فقد بدأ الخادم بشكل طبيعي ولم يُصدر أي تحذير؛ لذلك فإن أي نشر تم تكوينه بالطريقة الموثّقة كان يفرض بصمت حمايةً أقل مما اعتقد المشغّل أنه فعّلها، كما أن توثيق المكوّن نفسه عرض فحص التوقيع وانتهاء الصلاحية باعتباره السلوك الافتراضي، مع اعتبار المُصدِر (issuer) والجمهور المستهدَف (audience) إضافة اختيارية. تأثر كلٌّ من خادم التطبيق وخادم الإدارة، لأن الإغفال كان موجودًا في كلا مساري configureAuthentication. وبالتالي، كان يتم قبول أي رمز غير منتهي الصلاحية موقَّع بأي مفتاح يثق به مخزن المفاتيح المُهيَّأ، بغض النظر عن المُصدِر الذي أصدره أو الجمهور المستهدَف الذي كان موجَّهًا إليه. ويعتمد مدى تأثير ذلك على مجموعة الثقة في مخزن المفاتيح: فعندما ينتمي مفتاح التوقيع إلى مزوّد هوية مشترك أو متعدد المستأجرين (multi-tenant)، يُقبل رمز صدر بشكل مشروع لجمهور مختلف تمامًا؛ بينما يؤدي مخزن المفاتيح الذي يحتوي مُوقِّعًا مخصصًا إلى حصر ذلك في إعادة استخدام رموز صدرت لخدمات أخرى داخل نطاق الثقة نفسه. لم يكن الخياران jwtIssuer و jwtAudience موجودَين قبل الإصدار 4.21.0، لذلك لم تكن هناك أي طريقة مدعومة لفرض التحقق من هذه الادعاءات على الإطلاق في الإصدارات الأقدم. يُنصح المستخدمون بالترقية إلى الإصدار 4.22.0، الذي يعالج هذه المشكلة. فابتداءً من الإصدار 4.22.0، يرفض الخادم البدء عندما يتم تكوين مخزن مفاتيح JWT دون تعيين أيٍّ من jwtIssuer أو jwtAudience، مع ذكر الخصائص المعنية؛ كما يجب على أي نشر يرغب فعلًا في التحقق من التوقيع وانتهاء الصلاحية فقط أن يصرّح بذلك صراحةً عبر الخيار الجديد jwtAllowMissingIssuerAndAudience، الذي تبلغ قيمته الافتراضية false. تم إصلاح هذا السلوك في الإصدار 4.22.0 فقط. لا يغيّر الإصداران 4.14.9 و 4.18.4 السلوك الافتراضي: فهما يضيفان الخيارين jwtIssuer و jwtAudience بحيث يمكن للمشغّلين على خطّي الصيانة هذين فرض التحقق من الادعاءات عبر التكوين؛ غير أن أي تثبيت تتم ترقيته إلى 4.14.9 أو 4.18.4 دون تعيين واحدة على الأقل من هاتين الخاصيتين سيظل يقبل أي رمز غير منتهي الصلاحية موقَّع بمفتاح موثوق. لذلك، ينبغي على المستخدمين الذين يعملون على 4.14.x أو 4.18.x الترقية إلى 4.14.9 أو 4.18.4 ثم تعيين jwtIssuer أو jwtAudience أو كليهما. لا توفّر الإصدارات من 4.8.0 حتى 4.21.x ضمنًا أي وسيلة لفرض التحقق من هذه الادعاءات، وينبغي الانتقال منها إلى إصدار يدعم ذلك. وبصرف النظر عن الإصدار، قيّد مخزن مفاتيح JWT على أصغر مجموعة ثقة ممكنة، ومن الأفضل أن يكون مُوقِّعًا مخصصًا لهذه الخدمة بدلًا من مفتاح مزوّد هوية مشترك؛ وإذا كانت هناك بوابة (gateway) تتحقق بالفعل من المُصدِر والجمهور أمام الخادم، فتأكد من عدم إمكانية تجاوزها. ملاحظات: تشير تذكرة JIRA: https://issues.apache.org/jira/browse/CAMEL-24281 إلى مختلف الالتزامات التي عالجت المشكلة، وتتضمن مزيدًا من التفاصيل. تعذّر نقل آلية الإغلاق عند الفشل (fail-closed guard) إلى الإصدارات الأقدم. أما الخياران jwtIssuer و jwtAudience فلم يُقدَّما إلا في الإصدار 4.21.0 عبر CAMEL-23525؛ لذلك لم يكن هناك على camel-4.18.x و camel-4.14.x أي شيء يمكن للمشغّل تعيينه لتلبية هذا المتطلب، وكانت آلية الإغلاق عند الفشل ستُعطّل كل نشر يستخدم JWT على هذين الفرعين دون أي حل متاح.