CVE-2026-66906 in Camel
الملخص
بحسب VulDB • 24/08/2026
ثغرة عبور المسار النسبي في مكون Azure Storage Blob الخاص بـ Apache Camel.
تؤثر هذه المشكلة على Apache Camel: من الإصدار 4.0.0 قبل 4.14.9، ومن 4.15.0 قبل 4.18.4، ومن 4.19.0 قبل 4.22.0.
يمكن لمكون camel-azure-storage-blob تنزيل كتلة تخزين Azure (blob) إلى نظام الملفات المحلي من خلال عملية downloadBlobToFile الخاصة به، حيث يكتب في الدليل الذي يحدده خيار نقطة النهاية fileDir، والذي يُذكر كونه قابلاً للاستخدام من كل من المنتج والمستهلك. تقوم العملية BlobOperations.downloadBlobToFile ببناء الهدف المحلي عن طريق دمج fileDir مع اسم الكتلة البعيدة تماماً كما أبلغت عنه SDK الخاص بـ Azure (new File(fileDir, client.getBlobName())) ثم تمرر النتيجة مباشرة إلى استدعاء التنزيل في الـ SDK، دون أي تطبيع لغوي (lexical normalization) ودون التحقق من أن الموقع المحل stays داخل fileDir. اسم الكتلة ليس بيانات خاضعة لسيطرة المسار: يقوم المستهلك بتعداد الحاوية في BlobConsumer.createBatchExchangesFromContainer، والذي يسرد الكتل وينشئ تبادل واحد لكل إدخال بناءً على getName() الخاص بـ BlobItem حرفياً (verbatim)، دون تطبيق أي تصفية للأسماء افتراضياً. لذلك، يؤدي اسم كتلة يحتوي على مقاطع دليل أبوي إلى حل موقع خارج fileDir المكونة، مما يتيح لأي شخص قادر على التأثير في الأسماء الموجودة في الحاوية المستهلكة أن يتسبب في إنشاء Camel أو الكتابة فوق ملف في موقع يختاره هو نفسه، باستخدام امتيازات عملية Camel. واعتماداً على ما يمكن للعملية كتابته إليه، قد يؤدي تجاوز كتابة ملف خارج دليل التنزيل إلى تصعيد الخطأ بما يفوق مجرد فقدان سلامة ذلك الملف. تستخدم حاويات كتل تخزين Azure مساحة اسم مسطحة (flat namespace) حيث يكون اسم الكتلة مفتاحاً غامضاً، لذا يتم حفظ الاسم وتسريده كما هو مقدم. خيار fileDir هو معلمة تكوين عادية شائعة ولا يحمل أي علامة أمان، لذلك لم يكن هناك ما يشير إلى المستخدمين بأن قيمته لا تُفرض كحد للحصر (containment boundary). المستهلكون الآخرون لتحميل الملفات في Camel - camel-file وcamel-ftp وcamel-smb وcamel-mina-sftp وcamel-azure-files - قيدوا بالفعل تنزيلاتهم المحلية على الدليل المكون باستخدام فحص حد مقطع المسار؛ ولم يكن مسار التنزيل في camel-azure-storage-blob مشمولاً بهذا العمل.
يُنصح المستخدمون بالترقية إلى الإصدار 4.22.0، الذي يصلح المشكلة. إذا كان المستخدمون يستخدمون سلسلة إصدارات LTS الخاصة بـ 4.14.x، فيُقترح عليهم الترقية إلى 4.14.9. وإذا كانوا على سلسلة إصدارات 4.18.x، فيُقترح عليهم الترقية إلى 4.18.4. بالنسبة للتوزيعات التي لا يمكنها الترقية فوراً، يُنصح بتقييد الأسماء التي سيعمل عليها المستهلك باستخدام خيار نقطة النهاية regex، والذي يتم تطبيقه على كل اسم كتلة مدرجة كـ تطابق كامل للسلسلة (full-string match)، بحيث يتم قبول الأسماء البسيطة ذات المقطع الواحد فقط ويتم تصفية أي اسم يحمل فاصل مسار أو مقطع دليل أبوي قبل إنشاء التبادل؛ ويمكن لخيار prefix أيضاً تضييق القائمة من جانب الخادم، مع ملاحظة أنه عند تعيين كلا الخيارين، يأخذ regex الأولوية ويتجاهل prefix. كبديل آخر، تجنب عملية downloadBlobToFile على الحاويات غير الموثوقة واكتب الحمولة (payload) من المسار تحت اسم ملف يتحكم فيه المسار نفسه، بدلاً من واحد مأخوذ من القائمة البعيدة. كدفاع متعدد الطبقات، تعامل مع أسماء الكتل في أي حاوية قابلة للكتابة خارجياً كمُدخلات غير موثوقة ولا تستمد منها مسارات نظام الملفات المحلي.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.