CVE-2026-85248 — camel-pqc: समवर्ती Signature रेस (हस्ताक्षर सत्यापन बायपास)

Apache Camel भेद्यता के लिए चलाने योग्य प्रूफ-ऑफ-कॉन्सेप्ट पुनरुत्पादक, जहाँ PQC प्रोड्यूसर ने एक ही java.security.Signature इंस्टेंस रखा और बिना सिंक्रोनाइज़ेशन के हर एक्सचेंज के लिए उसका उपयोग किया। Signature स्टेटफुल है और थ्रेड-सेफ नहीं है: update() उस डेटा को जमा करता है जिसे साइन या वेरिफाई किया जाना है, और verify()/sign() उस जमा किए गए स्टेट का उपभोग करते हैं। समवर्ती एक्सचेंजों द्वारा एक ही इंस्टेंस साझा करने पर विभिन्न संदेशों के update और verify कॉल एक-दूसरे में गुंथ जाते हैं, इसलिए एक सत्यापन उस डेटा के विरुद्ध पूर्ण हो सकता है जो किसी अन्य एक्सचेंज का है, या आंशिक रूप से जमा किए गए बफ़र के विरुद्ध। परिणाम अनिर्धारित (non-deterministic) है और इसमें ऐसे संदेश के लिए सफलता की रिपोर्ट करने वाला सत्यापन भी शामिल है जिसके हस्ताक्षर वास्तव में कभी जाँचे ही नहीं गए, जो उस गारंटी को विफल कर देता है जिसे प्रदान करने के लिए यह घटक विद्यमान है। इसे प्राप्त करने के लिए केवल एक ही एंडपॉइंट से होकर समवर्ती ट्रैफ़िक की आवश्यकता होती है — जो लोड के अधीन Camel रूट के लिए सामान्य स्थिति है।

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

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

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

एक रूट प्रत्येक संदेश को पोस्ट-क्वांटम ML-DSA कुंजी से साइन करता है और फिर तुरंत उसी हस्ताक्षर को सत्यापित करता है जो उसने अभी उत्पन्न किया था, इसलिए प्रत्येक वैध रूप से साइन किए गए संदेश का सत्यापन true होना चाहिए। ड्राइवर इनमें से 1024 sign→verify राउंड-ट्रिप को साझा pqc: प्रोड्यूसरों के माध्यम से समवर्ती रूप से (16 थ्रेड्स) चलाता है।

• प्रभावित: 1024 सत्यापनों में से सैकड़ों true नहीं लौटाते — कुछ false लौटाते हैं, कुछ सिग्नेचर-इंजन त्रुटियाँ उत्पन्न करते हैं — क्योंकि समवर्ती एक्सचेंजों में साझा किया गया एकल स्टेटफुल Signature इंटरलीविंग से दूषित हो जाता है। अब कोई निर्णय उस संदेश के अनुरूप नहीं रहता जिसके लिए उसकी गणना की गई थी। (यही रेस, खतरनाक दिशा में, किसी ऐसे डेटा के लिए verify() को सफल होने देती है जिसे उसने कभी कवर ही नहीं किया।)
• ठीक किया गया: सभी 1024 राउंड-ट्रिप सत्यापित होते हैं, क्योंकि प्रत्येक एक्सचेंज अपना स्वयं का Signature इंस्टेंस उपयोग करता है।

# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: many of 1024 broken; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85248-pqc-signature-race-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: 0 broken; >>> 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): many broken
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: 0 broken

यह रेस, अपनी प्रकृति से, टाइमिंग-निर्भर है; रिप्रोड्यूसर पर्याप्त समवर्तीता (1024 राउंड-ट्रिप) चलाता है ताकि यह प्रभावित बिल्ड पर विश्वसनीय रूप से प्रकट हो। यदि किसी प्रभावित रन में कभी 0 broken दिखे, तो उसे फिर से चलाएँ।

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

गुण	मान
घटक	camel-pqc (PQCProducer हस्ताक्षर/सत्यापन)
CWE	CWE-362 (अनुचित सिंक्रोनाइज़ेशन के साथ साझा संसाधन का उपयोग करते हुए समवर्ती निष्पादन)
गंभीरता	MEDIUM
आक्रमण वेक्टर	एक ही स्टेटफुल java.security.Signature साझा करने वाले समान pqc: एंडपॉइंट के माध्यम से समवर्ती ट्रैफ़िक
प्रभाव	गैर-नियतात्मक हस्ताक्षर सत्यापन; एक सत्यापन ऐसे संदेश के लिए सफलता रिपोर्ट कर सकता है जिसका हस्ताक्षर कभी जाँचा ही नहीं गया
प्रभावित संस्करण	4.12.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक
ठीक किए गए संस्करण	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24445
श्रेय	Claude Security Scan Tool

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

समाधान

PQCProducer अब समवर्ती एक्सचेंजों के बीच Signature साझा नहीं करता। जब प्रोड्यूसर ने इंस्टेंस स्वयं बनाया था, तो अब यह प्रत्येक एक्सचेंज के लिए एक नया इंस्टेंस बनाता है (signerForExchange()); जब उपयोगकर्ता ने एक (JVM-व्यापी public static final) इंस्टेंस कॉन्फ़िगर किया था, तो उस तक पहुँच synchronized है। किसी भी स्थिति में, कोई भी दो एक्सचेंज एक ही इंस्टेंस पर अपने init/update/verify अनुक्रमों को इंटरलीव नहीं करते।

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

प्रभावित रूट को एकल समवर्ती उपभोक्ता तक सीमित करें ताकि कोई भी दो एक्सचेंज एक साथ Signature इंस्टेंस का उपयोग न करें।

अस्वीकरण

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