CVE-2026-83531

सारांश

Apache Camel में 'कोड इंजेक्शन' (कोड के निर्माण का अनुचित नियंत्रण) और 'एक्सप्रेशन लैंग्वेज इंजेक्शन' (एक्सप्रेशन लैंग्वेज स्टेटमेंट में प्रयुक्त विशेष तत्वों का अनुचित निष्प्रभावीकरण) की भेद्यता। यह समस्या Apache Camel को प्रभावित करती है: 4.4.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक। 4.4.0 में पेश किया गया dynamic-router-control एंडपॉइंट, रूटिंग प्रतिभागियों को नियंत्रण संदेश भेजकर Dynamic Router सदस्यताओं को प्रबंधित करने की अनुमति देता है। जब यह किसी subscribe या update अनुरोध को संभालता था, तो DynamicRouterControlProducer आने वाले संदेश से सदस्यता predicate और उसे संकलित करने के लिए उपयोग की जाने वाली भाषा का नाम लेता था, या तो किसी DynamicRouterControlMessage बॉडी के predicate और expressionLanguage फ़ील्ड से, या CamelDynamicRouterPredicate और CamelDynamicRouterExpressionLanguage हेडर से। इसके बाद DynamicRouterControlService उस भाषा को CamelContext से हल करता था और अभिव्यक्ति को एक Predicate में संकलित करता था, बिना किसी allow-list और बिना किसी opt-in के। संकलित predicate को चैनल के rule base में जोड़ा जाता था और जब तक सदस्यता मौजूद रहती थी, तब तक संबंधित dynamic-router एंडपॉइंट के माध्यम से रूट किए गए प्रत्येक exchange के विरुद्ध उसका मूल्यांकन किया जाता था। इसलिए, एक ऐसा रूट जो किसी बाहरी ट्रांसपोर्ट से संदेशों को नियंत्रण एंडपॉइंट तक अग्रेषित करता है, जैसा कि अन्य JVM या अनुप्रयोगों में रूटिंग प्रतिभागियों के लिए कंपोनेंट दस्तावेज़ में दिखाया गया है, किसी भी ऐसे अभिनेता को जो उस ट्रांसपोर्ट पर संदेश भेज सकता है, अपनी पसंद की अभिव्यक्ति प्रदान करने देता था, जिसका मूल्यांकन Camel प्रक्रिया के विशेषाधिकारों के साथ किया जाता था। क्लासपाथ पर उपलब्ध कोई भी एक्सप्रेशन लैंग्वेज चुनी जा सकती थी, जिसमें simple भाषा भी शामिल है, जो हमेशा उपस्थित रहती है और हेडर पथ पर डिफ़ॉल्ट थी, इसलिए क्लासपाथ से वैकल्पिक एक्सप्रेशन लैंग्वेज हटाने से यह समस्या नहीं रुकी। शोषण के लिए ऐसे ट्रांसपोर्ट पर संदेश भेजने की क्षमता आवश्यक है जिसका रूट उसे dynamic-router-control एंडपॉइंट तक अग्रेषित करता है; किसी अन्य प्रमाणीकरण या उपयोगकर्ता इंटरैक्शन की आवश्यकता नहीं है। 4.4.0 से पहले के रिलीज़ प्रभावित नहीं हैं, क्योंकि उनका नियंत्रण चैनल predicate अभिव्यक्तियाँ केवल रूट लेखक द्वारा कॉन्फ़िगर किए गए एंडपॉइंट URI से लेता था। उपयोगकर्ताओं को संस्करण 4.23.0 में अपग्रेड करने की सलाह दी जाती है, जो इस समस्या को ठीक करता है। यदि उपयोगकर्ता 4.22.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.22.1 में अपग्रेड करने का सुझाव दिया जाता है। यदि उपयोगकर्ता 4.18.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.18.5 में अपग्रेड करने का सुझाव दिया जाता है। 4.14.x रिलीज़ स्ट्रीम और उससे पहले की स्ट्रीम इस समस्या के समाधान से पहले ही end of life तक पहुँच चुकी थीं और उन्हें कोई फ़िक्स नहीं मिलेगा, इसलिए उन लाइनों पर तैनातियों को किसी समर्थित रिलीज़ पर स्थानांतरित होना चाहिए। अपग्रेड करने के बाद, कोई भी नियंत्रण संदेश जो predicate अभिव्यक्ति या एक्सप्रेशन लैंग्वेज लेकर आता है, अस्वीकार कर दिया जाता है, जब तक कि dynamic-router-control एंडपॉइंट पर नया allowPredicateFromMessage विकल्प सक्षम न हो; इसे केवल तब सक्षम करें जब नियंत्रण संदेशों का प्रत्येक प्रेषक विश्वसनीय हो। उन तैनातियों के लिए जो तुरंत अपग्रेड नहीं कर सकते, अविश्वसनीय या साझा ट्रांसपोर्ट से संदेशों को dynamic-router-control एंडपॉइंट तक अग्रेषित न करें। जहाँ नियंत्रण संदेशों को ऐसे ट्रांसपोर्ट को पार करना ही हो, वहाँ प्रेषक का प्रमाणीकरण करें और सुनिश्चित करें कि प्रत्येक सदस्यता का predicate और एक्सप्रेशन लैंग्वेज आने वाले संदेश से लेने के बजाय रूट द्वारा सेट किए जाएँ, उदाहरण के लिए CamelDynamicRouterPredicate और CamelDynamicRouterExpressionLanguage हेडर हटाकर और एंडपॉइंट तक पहुँचने से पहले DynamicRouterControlMessage के predicate और expressionLanguage फ़ील्ड साफ़ करके। क्लासपाथ से वैकल्पिक एक्सप्रेशन लैंग्वेज हटाना पर्याप्त उपाय नहीं है। रक्षा की गहराई के रूप में, यह प्रतिबंधित करें कि कौन नियंत्रण एंडपॉइंट को फ़ीड करने वाले ट्रांसपोर्ट पर भेज सकता है, और 4.23.0 और 4.22.1 पर dynamic-router एंडपॉइंट के allowedSchemes विकल्प को सेट करें ताकि यह सीमित हो सके कि किसी सदस्यता का destinationUri किन एंडपॉइंट्स को नामित कर सकता है।