CVE-2026-88900 — camel-jgroups: क्लस्टर संदेशों का असुरक्षित Java डीसेरियलाइज़ेशन

Apache Camel की उस भेद्यता के लिए चलाने योग्य प्रूफ-ऑफ-कॉन्सेप्ट रिप्रोड्यूसर, जिसमें jgroups consumer बिना किसी फ़िल्टर के क्लस्टर संदेशों का Java डीसेरियलाइज़ेशन करता था। JGroupsEndpoint.createExchange(Message) — जिसे consumer द्वारा प्राप्त प्रत्येक संदेश के लिए कॉल किया जाता है — exchange body को org.jgroups.Message.getObject() से सेट करता था। ObjectMessage के लिए (जो Camel jgroups producer भेजता है), JGroups संदेश आते ही payload को ObjectInputStream के माध्यम से Java-डीसेरियलाइज़ करता है, और getObject() परिणाम लौटाता है। कोई java.io.ObjectInputFilter लागू नहीं किया गया था, इसलिए क्लस्टर से प्राप्त application classpath पर मौजूद कोई भी serializable class इंस्टैंशिएट हो जाती थी और उसके deserialization callbacks चल जाते थे — उपयोगी gadget chain मौजूद होने पर remote code execution। स्टॉक new JChannel() स्टैक (UDP multicast, कोई AUTH नहीं, कोई encryption नहीं) के साथ, कोई भी होस्ट जो क्लस्टर तक पहुँच सकता है, बिना क्रेडेंशियल के ऐसा संदेश भेज सकता है (CWE-502)।

केवल Spring Boot। यह रिप्रोड्यूसर एक ही Camel Spring Boot मॉड्यूल के साथ आता है। camel-jgroups में camel-quarkus-jgroups एक्सटेंशन नहीं है, इसलिए रिप्रोड्यूस करने के लिए कोई Quarkus समकक्ष नहीं है। Spring Boot मॉड्यूल प्रभावित और ठीक किए गए व्यवहार दोनों को प्रदर्शित करता है।

Runtime	Directory	Stack
Camel Spring Boot	camel-spring-boot/	Spring Boot 3.5.13 + camel-jgroups 4.22.0 (प्रभावित; ठीक किया गया 4.22.1)

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

एक सौम्य हमलावर ऑब्जेक्ट — com.example.Marker, एक सामान्य application class जो fix की डिफ़ॉल्ट allow-list (java.**, javax.**, org.apache.camel.**) में नहीं है — को JGroups wire form में serialize किया जाता है और वास्तविक JGroupsEndpoint.createExchange(...) को दिया जाता है, जो इसे Message.getObject() से पढ़ता है (वही कॉल जो consumer प्रत्येक प्राप्त संदेश के लिए करता है)। किसी channel या multicast की आवश्यकता नहीं है, इसलिए जाँच नियतात्मक (deterministic) है। Marker.readObject एक फ़्लैग पलटता है ताकि दिखे कि deserialization callback चलता है — एक वास्तविक gadget chain उसी बिंदु पर हानिकारक कोड चलाती; इस रिप्रोड्यूसर में कोई gadget नहीं है।

• प्रभावित: Marker डीसेरियलाइज़ होता है और exchange body के रूप में सेट होता है — एक मनमानी हमलावर class route तक पहुँच जाती है।
• ठीक किया गया: एक डिफ़ॉल्ट allow-list class जाँच com.example.Marker को अस्वीकार करती है और createExchange JGroupsException फेंकता है; ऑब्जेक्ट कभी route तक नहीं पहुँचता।

ईमानदार चेतावनी (जैसा advisory में कहा गया है): 4.22.1 / 4.18.5 class जाँच JGroups द्वारा payload डीसेरियलाइज़ करने के बाद चलती है, इसलिए readObject callback ठीक किए गए build पर भी चलता है — यह defense-in-depth है। डीसेरियलाइज़ेशन के दौरान चलने वाले कोड को रोकने के लिए आपको JVM-व्यापी -Djdk.serialFilter भी सेट करना होगा और channel को AUTH + encryption से सुरक्षित करना होगा; 4.23.0 अतिरिक्त रूप से consumer शुरू करने से मना कर देता है जब तक उन नियंत्रणों में से एक कॉन्फ़िगर न हो। यह रिप्रोड्यूसर class-check अंतर दिखाता है; callback-ran फ़्लैग चेतावनी को दृश्यमान बनाता है।

cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: Marker deserialized + routed; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-88900-jgroups-deserialization-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: JGroupsException rejects com.example.Marker; >>> Not exploited

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

गुण	मान
घटक	camel-jgroups (JGroupsEndpoint.createExchange)
CWE	CWE-502 (अविश्वसनीय डेटा का डीसेरियलाइज़ेशन)
गंभीरता	उच्च
आक्रमण वेक्टर	क्लस्टर के मल्टीकास्ट समूह / बाइंड पोर्ट तक पहुँच रखने वाला कोई होस्ट एक तैयार किया गया ObjectMessage भेजता है; उपभोक्ता इसे बिना किसी फ़िल्टर के डीसेरियलाइज़ करता है
प्रभाव	जब क्लासपाथ पर गैजेट चेन मौजूद हो तो Camel प्रक्रिया में रिमोट कोड निष्पादन; अन्यथा मनमाना क्लास इंस्टैंशिएशन
प्रभावित संस्करण	4.0.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक
ठीक किए गए संस्करण	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24676, CAMEL-25223
रिपोर्ट करने वाला	h1ei1

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

समाधान

JGroupsEndpoint अब एक्सचेंज के रूट होने से पहले Message.getObject() द्वारा लौटाए गए बॉडी के क्लास की जाँच करता है, एक नए deserializationFilter विकल्प (jdk.serialFilter सिंटैक्स) के माध्यम से। जब यह सेट नहीं होता, तो यदि मौजूद हो तो JVM-व्यापी jdk.serialFilter का पालन किया जाता है, अन्यथा एक रूढ़िवादी डिफ़ॉल्ट अनुमति-सूची java.**/javax.**/org.apache.camel.** की अनुमति देती है, java.net.** को अस्वीकार करती है और बाकी सभी को अस्वीकार करती है; अस्वीकृत संदेश की सूचना उपभोक्ता के ExceptionHandler को दी जाती है और उसे रूट नहीं किया जाता। 4.23.0 (CAMEL-25223) में उपभोक्ता स्टार्ट होने से इंकार भी कर देता है जब तक कि डीसेरियलाइज़ेशन से पहले कार्य करने वाला कोई नियंत्रण कॉन्फ़िगर न किया गया हो (JVM-व्यापी फ़िल्टर, jgroups.deserialization.filter सिस्टम प्रॉपर्टी, या AUTH+एन्क्रिप्शन चैनल)। acceptAllObjects=true पुराने व्यवहार को बहाल करता है और इसे असुरक्षित सेटिंग के रूप में चिह्नित किया गया है।

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

उपभोक्ता चलाने वाले JVM पर -Djdk.serialFilter सेट करें (केवल उन क्लासों की अनुमति दें जिन्हें आपके रूट क्लस्टर पर एक्सचेंज करते हैं), channelProperties विकल्प के माध्यम से चैनल को AUTH और SYM_ENCRYPT/ASYM_ENCRYPT से सुरक्षित करें, और क्लस्टर के मल्टीकास्ट समूह या बाइंड पोर्ट को अविश्वसनीय नेटवर्क के सामने उजागर न करें।

अस्वीकरण

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