oscerd/cve-2026-85247مُعيد إنتاج قابل للتشغيل لـ Spring Boot وQuarkus من أجل CVE-2026-85247، يوضّح سلوك camel-knative الاحتياطي القائم على الثقة الكاملة بـ TLS ويتحقق من الإصلاح.
مُعيد إنتاج عملي قابل للتشغيل لثغرة Apache Camel حيث أدى تفعيل SSL على عميل Knative HTTP دون تكوين truststore إلى الرجوع إلى الوثوق بكل شهادة مُقدَّمة بدلاً من الرجوع إلى مراسي الثقة الافتراضية في JVM. وبالتالي، فإن أي نشر فعّل TLS دون تكوين truststore أيضاً حصل على اتصال مشفّر دون أي مصادقة على الطرف الآخر، وهو اتصال يمكن لمهاجم يتمركز على مسار الشبكة إنهاؤه وقراءته. تُبلَغ الحالة الخطرة بالإغفال، لا بالاشتراك الصريح — فتفعيل TLS لا ينبغي أن يكون هو ما يُعطّل التحقق من الشهادة.
| بيئة التشغيل | الدليل | المكدّس |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-knative 4.22.0 (متأثر؛ مُصلَح في 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-knative (Camel 4.15.0، متأثر؛ عنصر التحكم المُصلَح CQ 3.40.0 / Camel 4.22.1) |
يُظهر كلا الوحدتين السلوك المتأثر و السلوك المُصلَح.
يضبط النشر camel.knative.client.ssl.enabled=true ولا يكوّن أي truststore. يبني برنامج التشغيل
KnativeSslClientOptions الحقيقي من تلك الإعدادات بالضبط — نفس الخيارات التي يستخدمها منتج Knative HTTP — ويُجري
طلب HTTPS بها إلى خادم مُضمَّن يقدّم شهادة موقّعة ذاتياً (CN=localhost، غير موجودة في أي truststore)، ليقوم مقام
هجوم رجل في المنتصف عبر TLS.
KnativeSslClientOptions.getTrustOptions() هي TrustAllOptions، لذا يقبل العميل الشهادة الموقّعة
ذاتياً وينجح الطلب — مشفّراً لكن دون مصادقة.SunCertPathBuilderException: unable to find valid certification path.# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: trusts the self-signed cert; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85247-knative-cert-validation-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: handshake fails; >>> Not exploited
# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected (Camel 4.15.0): trusts the self-signed cert
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack # fixed: handshake fails
| الخاصية | القيمة |
|---|---|
| المكوّن | camel-knative (KnativeSslClientOptions.configureOptions) |
| CWE | CWE-295 (التحقق غير السليم من الشهادات) |
| الخطورة | متوسطة |
| ناقل الهجوم | هجوم رجل في المنتصف عبر الشبكة ضد عميل Knative HTTP الذي فعّل SSL لكنه لم يضبط أي truststore |
| التأثير | اتصال مشفّر دون مصادقة الطرف الآخر: يتم الوثوق بأي شهادة، لذا يمكن اعتراض TLS وقراءته |
| الإصدارات المتأثرة | من 4.0.0 قبل 4.18.5، ومن 4.19.0 قبل 4.22.1 |
| الإصدارات المُصلحة | 4.18.5، 4.22.1، 4.23.0 |
| JIRA | CAMEL-24443 |
| الفضل | Claude Security Scan Tool |
الإشعار الأمني: https://camel.apache.org/security/CVE-2026-85247.html
ملف server-keystore.p12 المرفق هو زوج مفاتيح ذاتي التوقيع مؤقت (CN=localhost) تم إنشاؤه فقط لأجل هذا
المُعيد لإنتاج المشكلة.
KnativeSslClientOptions.configureOptions: عند تفعيل SSL دون
keystore أو truststore أو مسار trust-cert، تُترك خيارات الثقة الآن دون ضبط، بحيث يعود Vert.x إلى
مراسي الثقة الافتراضية في JVM — وهو نفس السلوك الاحتياطي الذي تستخدمه SSLContextParameters وبقية Camel. أصبح
الوصول إلى TrustAllOptions الآن متاحًا فقط عبر ضبط camel.knative.client.ssl.trust.all=true صراحةً (وهو ما يبقى
متاحًا للتطوير ضد عنقود يستخدم شهادة ذاتية التوقيع). بعد الترقية، يجب على أي نشر كان يعتمد على سلوك الثقة الضمنية
بالكل إما ضبط truststore أو تعيين trust.all عن قصد.
اضبط truststore صراحةً في كل مكان يتم فيه تفعيل SSL على عميل Knative HTTP.
يُنشر هذا المستودع لأغراض تعليمية ودفاعية: لمساعدة مستخدمي Apache Camel على فهم الثغرة الأمنية، والتحقق مما إذا كانوا متأثرين بها، وتأكيد أن الترقية تحلّها. إن keystore ذاتي التوقيع هو ملف محلي خامل. لا تستخدم هذه المواد ضد أنظمة لا تملكها أو لا تديرها.