CVE-2026-101259 — camel-coap: उपभोक्ता ने अपवाद संदेश CoAP क्लाइंट को भेज दिया

Apache Camel भेद्यता के लिए रन करने योग्य प्रमाण-अवधारणा पुनरुत्पादक, जिसमें जब CoAP उपभोक्ता अपनी प्रतिक्रिया नहीं बना सका मार्ग पूर्ण हो जाने के बाद, CamelCoapResource ने परिणामी अपवाद को पकड़ लिया और उसका संदेश 5.00 Internal Server Error के पेलोड के रूप में CoAP क्लाइंट को वापस भेज दिया:

} catch (Exception e) {
    cexchange.respond(ResponseCode.INTERNAL_SERVER_ERROR, e.getMessage());
}

रनटाइम	निर्देशिका	स्टैक
Camel Spring Boot	`camel-spring-boot/`	Spring Boot 3.5.13 + camel-coap 4.22.1
Camel Quarkus	`camel-quarkus/`	Camel Quarkus 3.39.0 (Quarkus 3.39.0, Camel 4.22.0)

"रूट पूरा होने के बाद" क्यों मायने रखता है

कंज़्यूमर अंतिम संदेश बॉडी को byte[] पेलोड में, और CamelCoapMaxAge तथा CamelCoapETag हेडर को उनके प्रकारों में, रूट के लौटने के बाद — और इसलिए रूट के त्रुटि हैंडलर के बाहर — परिवर्तित करता है। रूट में एक onException इसे नहीं पकड़ सकता, क्योंकि विफलता कंज़्यूमर में होती है, रूट में नहीं।

cd camel-spring-boot          # or: cd camel-quarkus
mvn clean package
docker compose up -d --build
until [ "$(curl -s http://localhost:8080/exploit/ready)" = "Started" ]; do sleep 1; done
curl -s http://localhost:8080/exploit/attack
docker compose down

प्रभावित बिल्ड पर आउटपुट (दोनों रनटाइम्स पर समान):

1) Converting the body to the byte[] payload fails once the route has completed
     CoAP GET coap://127.0.0.1:5683/reading
     response code    : 5.00 (INTERNAL_SERVER_ERROR)
     response payload : Error during type conversion from type: com.example.FailingBackendStream to the
                        required type: byte[] with value com.example.FailingBackendStream@5eede7d7 due to
                        java.io.IOException: connection to prod-db.internal:5432 reset while streaming
                        sensor_readings for node edge-gateway-07.dc2.internal

2) The CamelCoapMaxAge header cannot be converted to its type
     CoAP GET coap://127.0.0.1:5683/reading-maxage
     response code    : 5.00 (INTERNAL_SERVER_ERROR)
     response payload : Error during type conversion from type: java.lang.String to the required type:
                        java.lang.Long with value not-a-number due to java.lang.NumberFormatException:
                        For input string: "not-a-number"

3) A route that simply fails
     CoAP GET coap://127.0.0.1:5683/reading-failing
     response code    : 2.05 (CONTENT)
     response payload : partially built response

What a remote CoAP client learned from these responses:
  the backend host and port, out of the cause's message : true
  class names of the cause                             : true
  the source and target types of the conversion        : true
  the string form of the offending value               : true
  a failed route answered with a SUCCESS code          : true

>>> PROVEN: ...

ऐसी विफलता का संदेश उस मान के वर्ग का नाम बताता है जिसे परिवर्तित किया जा रहा है, उस मान का स्ट्रिंग रूप लेकर चलता है, और अंतर्निहित कारण के वर्ग नाम और संदेश के साथ समाप्त होता है — इसलिए एक रिमोट CoAP क्लाइंट ने वर्ग और पैकेज नाम, मान का स्ट्रिंग रूप, और जो कुछ भी कारण लेकर चलता है, पढ़ लिया, जिसमें व्यवहार में बैकएंड के पथ, होस्ट नाम और कनेक्शन विवरण शामिल हो सकते हैं। उपभोक्ता के पास इसे दबाने का कोई विकल्प नहीं था, HTTP उपभोक्ताओं के विपरीत, जो इस उद्देश्य के लिए muteException प्रदान करते हैं।

प्रोब 3 इस समस्या का दूसरा आधा भाग है। विफल होने वाले रूट द्वारा उठाया गया अपवाद बिल्कुल नहीं भेजा गया था: उपभोक्ता ने यह जाँच नहीं की कि एक्सचेंज विफल हुआ था या नहीं, और रूट विफलता का उत्तर 2.05 Content और उस समय संदेश में जो भी बॉडी थी, उसके साथ दिया — एक विफल रूट के लिए सफलता कोड।

इस रिप्रोड्यूसर को एक बात सही करनी थी: ऐसी बॉडी जिसके लिए कोई कनवर्टर मौजूद नहीं है, पर्याप्त नहीं है। उस स्थिति में getBody(byte[].class) अपवाद फेंकने के बजाय null लौटाता है, और फिर उपभोक्ता खाली पेलोड के साथ 2.05 का उत्तर देता है — कोई प्रकटीकरण नहीं। रूपांतरण को विफल होना चाहिए, अनुपलब्ध नहीं होना चाहिए, यही कारण है कि प्रोब 1 एक स्ट्रीम बॉडी का उपयोग करता है जो पढ़ने के बीच में अपवाद फेंकता है। हेडर प्रोब दूसरे तरीके से विफल होता है, गलत आकार के मान के माध्यम से।

पहुँच-योग्यता

प्रकटीकरण तक पहुँचने के लिए ऐसे रूट की आवश्यकता होती है जिसके पूर्ण प्रतिक्रिया को एक रिमोट क्लाइंट अपरिवर्तनीय बना सके, जो इस बात पर निर्भर करता है कि रूट कैसे लिखा गया है। यहाँ कुछ भी प्रमाणित नहीं है, और सादे CoAP GET ही सब कुछ हैं जो क्लाइंट भेजता है।

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

गुण	मान
घटक	`camel-coap` (`CamelCoapResource`)
CWE	CWE-209 (संवेदनशील जानकारी युक्त त्रुटि संदेश का निर्माण)
गंभीरता	मध्यम
आक्रमण वेक्टर	एक उपभोक्ता को CoAP अनुरोध जिसकी पूर्ण प्रतिक्रिया नहीं बनाई जा सकती — ऐसी बॉडी जो `byte[]` में रूपांतरण में विफल हो, या `CamelCoapMaxAge` / `CamelCoapETag` हेडर जो रूपांतरण में विफल हो
प्रभाव	एक रिमोट CoAP क्लाइंट वर्ग और पैकेज नाम, मान का स्ट्रिंग रूप और अंतर्निहित कारण का संदेश पढ़ लेता है — व्यवहार में पथ, होस्ट नाम और बैकएंड कनेक्शन विवरण
प्रभावित संस्करण	4.0.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.2 से पहले तक
ठीक किए गए संस्करण	4.18.5, 4.22.2, 4.23.0
JIRA	CAMEL-25087
श्रेय	Zhixi "Jace" Sun, स्वतंत्र सुरक्षा शोधकर्ता

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

समाधान

उपभोक्ता को एक muteException विकल्प मिलता है — coap, coaps, coap+tcp और coaps+tcp एंडपॉइंट्स पर समान रूप से — जो सभी तीन ठीक किए गए रिलीज़ लाइनों पर डिफ़ॉल्ट रूप से true है, इसलिए अपग्रेड अपने आप में पर्याप्त है और किसी कॉन्फ़िगरेशन परिवर्तन की आवश्यकता नहीं है। उपभोक्ता अभी भी 5.00 Internal Server Error का उत्तर देता है, लेकिन खाली पेलोड के साथ, और अब यह उपभोक्ता के अपवाद हैंडलर के माध्यम से अपवाद की रिपोर्ट करता है, इसलिए इसे म्यूट करना इसे ऑपरेटर से नहीं छिपाता।

यह यह भी जाँचता है कि एक्सचेंज विफल हुआ था या नहीं, और उसी नियम के अंतर्गत रूट विफलता का उत्तर 5.00 Internal Server Error देता है, जहाँ पहले यह 2.05 Content का उत्तर देता था।

main पर apache/camel#26994 (2245feac) में ठीक किया गया, बैकपोर्ट camel-4.22.x में #27046 (868d5604) और camel-4.18.x में #27048 (aaf5bbf8) में।

ठीक किए गए बिल्ड की जाँच

camel.version को 4.22.2 पर सेट करें और इसे फिर से चलाएँ। 4.22.1 → 4.22.2 के विरुद्ध सत्यापित:

1) ... response code: 5.00 (INTERNAL_SERVER_ERROR)   response payload : <empty>
2) ... response code: 5.00 (INTERNAL_SERVER_ERROR)   response payload : <empty>
3) ... response code: 5.00 (INTERNAL_SERVER_ERROR)   response payload : <empty>

>>> NOT reproduced: the error payload was empty.

Probe 3 भी कोड बदलता है, 2.05 Content से 5.00 Internal Server Error में — रूट विफलता अब विफलता के रूप में उत्तरित होती है।

अपग्रेड किए बिना शमन

सुनिश्चित करें कि रूट पूरा होने के बाद प्रतिक्रिया हमेशा बनाई जा सके: coap endpoint से उपभोग करने वाले प्रत्येक रूट के अंतिम चरण के रूप में बॉडी को byte[] या String में परिवर्तित करें (convertBodyTo), CamelCoapMaxAge और CamelCoapETag हेडर को केवल उनके अपने प्रकार के मान दें, और एक onException हैंडलर जोड़ें जो विफलता को हैंडल्ड के रूप में चिह्नित करे और प्रतिक्रिया बॉडी को स्पष्ट रूप से सेट करे — ताकि रूपांतरण विफलता उपभोक्ता में नहीं बल्कि रूट के अंदर उठाई और प्रतिस्थापित की जाए।

CVE-2026-101259

सबसे लोकप्रिय