CVE-2026-85296 — camel-as2: क्रॉस-पार्टनर MDN साइनिंग कुंजी भ्रम

Apache Camel की उस भेद्यता के लिए चलाने योग्य प्रूफ-ऑफ-कॉन्सेप्ट पुनरुत्पादक, जिसमें प्रति-अनुरोध साइनिंग सामग्री अनुरोधों में साझा की गई स्थिति में रखी जाती थी, बजाय इसके कि वह संसाधित किए जा रहे अनुरोध तक सीमित रहे। एक एकल ResponseMDN साझा HttpProcessor पर पंजीकृत होता है और हर AS2 अनुरोध को सेवा देता है; डायनामिक-कीज़ कॉन्फ़िगरेशन में (प्रति पथ एक ट्रेडिंग पार्टनर, प्रत्येक की अपनी कुंजियाँ प्रति अनुरोध HttpContext से हल की जाती हैं) प्रभावित बिल्ड ने हल की गई प्रति-अनुरोध साइनिंग कुंजी को एक इंस्टेंस फ़ील्ड पर वापस लिख दिया। जहाँ कोई डिप्लॉयमेंट एक से अधिक पार्टनर को सेवा देता है, वहाँ समवर्ती या क्रमिक अनुरोध एक-दूसरे की सामग्री देख सकते थे, और एक Message Disposition Notification किसी भिन्न ट्रेडिंग पार्टनर की कुंजी से हस्ताक्षरित हो सकता था। AS2 डिप्लॉयमेंट डिज़ाइन से ही सामान्यतः बहु-पार्टनर होते हैं, इसलिए यह स्थिति सामान्य समवर्ती ट्रैफ़िक द्वारा पहुँची जाती है।

रनटाइम	निर्देशिका	स्टैक
Camel Spring Boot	camel-spring-boot/	Spring Boot 3.5.13 + camel-as2 4.22.0 (प्रभावित; ठीक किया गया 4.22.1)
Camel Quarkus	camel-quarkus/	Quarkus 3.39.0 + camel-quarkus-as2 (Camel 4.22.0, प्रभावित; ठीक किया गया नियंत्रण CQ 3.40.0 / Camel 4.22.1)

दोनों मॉड्यूल प्रभावित और ठीक किए गए व्यवहार को प्रदर्शित करते हैं।

यह क्या प्रदर्शित करता है

ड्राइवर वास्तविक ResponseMDN (AS2 प्रतिक्रिया इंटरसेप्टर) का उसके डायनामिक-कीज़ रूप में उपयोग करता है। यह बारी-बारी से दो पार्टनरों की साइनिंग सामग्री हल करता है — पहले Partner A, फिर Partner B — ResponseMDN.process(...) के माध्यम से (HttpContext में प्रत्येक की अपनी RSA कुंजी के साथ), और प्रत्येक के बाद इंस्टेंस का signingPrivateKey फ़ील्ड पढ़ता है।

• प्रभावित: Partner A का अनुरोध संभालने के बाद साझा इंस्टेंस Partner A की निजी कुंजी रखता है; Partner B के बाद यह Partner B की रखता है। प्रति-अनुरोध कुंजी साझा इंस्टेंस पर संग्रहीत होती है, इसलिए एक पार्टनर के लिए समवर्ती अनुरोध किसी दूसरे पार्टनर की कुंजी पढ़ सकता है — और उससे अपने MDN पर हस्ताक्षर कर सकता है।
• ठीक किया गया: फ़ील्ड final है और कभी लिखा नहीं जाता; प्रति-अनुरोध कुंजी अनुरोध तक ही सीमित रहती है, इसलिए साझा इंस्टेंस का signingPrivateKey null ही रहता है।

# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: per-request key on the shared instance; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85296-as2-signing-key-confusion-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: field stays null; >>> 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.22.0): per-request key on the shared instance
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: field stays null

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

Property	Value
घटक	camel-as2 (ResponseMDN dynamic-keys handling)
CWE	CWE-488 (Exposure of Data Element to Wrong Session)
गंभीरता	MEDIUM
आक्रमण वेक्टर	एक ही ResponseMDN इंस्टेंस साझा करने वाले बहु-साझेदार परिनियोजन में सामान्य समवर्ती AS2 ट्रैफ़िक
प्रभाव	किसी अन्य ट्रेडिंग पार्टनर की निजी कुंजी से हस्ताक्षरित Message Disposition Notification; साझेदारों के बीच साइनिंग-सामग्री का पुनः उपयोग
प्रभावित संस्करण	4.0.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक
ठीक किए गए संस्करण	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24429
श्रेय	Claude Security Scan Tool

सलाह: https://camel.apache.org/security/CVE-2026-85296.html

Quarkus प्रभावित मॉड्यूल CQ 3.39.0 (Camel 4.22.0) पर आधारित है: इस PoC द्वारा प्रयुक्त गतिशील प्रति-अनुरोध AS2 साइनिंग-कुंजी तंत्र CQ 3.29.0 (Camel 4.15.0) के बाद का है, इसलिए CQ 3.39.0 वही Camel 4.22.0 प्रदान करता है जो Spring Boot मॉड्यूल में है।

समाधान

ResponseMDN कॉन्फ़िगर किए गए सुरक्षा फ़ील्ड को final बनाता है और गतिशील प्रति-अनुरोध सामग्री को process() के अंदर लोकल में हल करता है, इसे कभी भी इंस्टेंस फ़ील्ड में वापस नहीं लिखता। इसलिए एक एकल साझा इंस्टेंस अब एक अनुरोध की साइनिंग कुंजी को दूसरे अनुरोध तक लीक नहीं कर सकता।

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

प्रत्येक ट्रेडिंग पार्टनर के लिए एक अलग Camel कॉन्टेक्स्ट चलाएँ ताकि उनके बीच कोई साइनिंग सामग्री साझा न हो।

अस्वीकरण

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