CVE-2026-85247 — camel-knative: अनुचित प्रमाणपत्र सत्यापन (TLS चालू करने से सत्यापन बंद हो जाता है)

Apache Camel की उस भेद्यता के लिए चलाने योग्य प्रूफ-ऑफ-कॉन्सेप्ट पुनरुत्पादक, जिसमें Knative HTTP क्लाइंट पर ट्रस्टस्टोर कॉन्फ़िगर किए बिना SSL सक्षम करने पर JVM के डिफ़ॉल्ट ट्रस्ट एंकर के बजाय हर प्रस्तुत प्रमाणपत्र पर भरोसा करने पर वापस चला जाता था। इसलिए, जिस डिप्लॉयमेंट ने ट्रस्टस्टोर भी कॉन्फ़िगर किए बिना TLS चालू किया, उसे बिना पीयर प्रमाणीकरण के एक एन्क्रिप्टेड कनेक्शन प्राप्त हुआ, जिसे नेटवर्क पथ पर स्थित हमलावर समाप्त करके पढ़ सकता है। यह खतरनाक स्थिति स्पष्ट ऑप्ट-इन से नहीं, बल्कि चूक से पहुँची जाती है — 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 सेट करता है और कोई ट्रस्टस्टोर कॉन्फ़िगर नहीं करता। ड्राइवर ठीक उन्हीं सेटिंग्स से वास्तविक KnativeSslClientOptions बनाता है — वही विकल्प जो Knative HTTP प्रोड्यूसर उपयोग करता है — और उनके साथ एक बंडल किए गए सर्वर को HTTPS अनुरोध करता है जो स्व-हस्ताक्षरित प्रमाणपत्र (CN=localhost, किसी भी ट्रस्टस्टोर में नहीं) प्रस्तुत करता है, जो TLS मैन-इन-द-मिडल का प्रतिनिधित्व करता है।

• प्रभावित: KnativeSslClientOptions.getTrustOptions() TrustAllOptions है, इसलिए क्लाइंट स्व-हस्ताक्षरित प्रमाणपत्र स्वीकार कर लेता है और अनुरोध सफल हो जाता है — एन्क्रिप्टेड लेकिन अनप्रमाणित।
• ठीक किया गया: ट्रस्ट विकल्प अनसेट छोड़ दिए जाते हैं, इसलिए JVM के डिफ़ॉल्ट ट्रस्ट एंकर लागू होते हैं, स्व-हस्ताक्षरित प्रमाणपत्र अस्वीकार कर दिया जाता है और TLS हैंडशेक 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

भेद्यता सारांश

Property	Value
Component	camel-knative (KnativeSslClientOptions.configureOptions)
CWE	CWE-295 (अनुचित प्रमाणपत्र सत्यापन)
Severity	MEDIUM
Attack vector	एक Knative HTTP क्लाइंट के विरुद्ध नेटवर्क मैन-इन-द-मिडल, जिसने SSL सक्षम किया था लेकिन कोई truststore कॉन्फ़िगर नहीं किया था
Impact	बिना पीयर प्रमाणीकरण के एन्क्रिप्टेड कनेक्शन: किसी भी प्रमाणपत्र पर भरोसा किया जाता है, इसलिए TLS को इंटरसेप्ट करके पढ़ा जा सकता है
Affected Versions	4.0.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक
Fixed Versions	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24443
Credit	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 पथ के सक्षम होता है, तो trust विकल्प अब अनसेट छोड़ दिए जाते हैं, इसलिए Vert.x JVM के डिफ़ॉल्ट trust anchors पर वापस चला जाता है — वही फ़ॉलबैक जो SSLContextParameters और शेष Camel उपयोग करते हैं। TrustAllOptions अब केवल camel.knative.client.ssl.trust.all=true को स्पष्ट रूप से सेट करके ही पहुँचा जाता है (जो स्व-हस्ताक्षरित प्रमाणपत्र वाले क्लस्टर के विरुद्ध विकास के लिए उपलब्ध रहता है)। अपग्रेड करने के बाद, जिस डिप्लॉयमेंट ने अंतर्निहित trust-all व्यवहार पर निर्भर किया था, उसे या तो truststore कॉन्फ़िगर करना होगा या जानबूझकर trust.all सेट करना होगा।

यदि आप अपग्रेड नहीं कर सकते तो शमन

जहाँ भी Knative HTTP क्लाइंट पर SSL सक्षम हो, वहाँ स्पष्ट रूप से truststore कॉन्फ़िगर करें।

अस्वीकरण

यह रिपॉज़िटरी शैक्षिक और रक्षात्मक उद्देश्यों के लिए प्रकाशित की गई है: Apache Camel उपयोगकर्ताओं को भेद्यता को समझने, यह सत्यापित करने कि क्या वे प्रभावित हैं, और पुष्टि करने में मदद करने के लिए कि अपग्रेड करने से यह हल हो जाती है। स्व-हस्ताक्षरित keystore एक निष्क्रिय स्थानीय फ़िक्स्चर है। इस सामग्री का उपयोग उन सिस्टमों के विरुद्ध न करें जो आपके स्वामित्व या संचालन में नहीं हैं।