CVE-2026-94386

सारांश

Apache Camel Oauth घटक में संवेदनशील जानकारी युक्त कैश के उपयोग की भेद्यता। यह समस्या Apache Camel को प्रभावित करती है: 4.19.0 से 4.22.2 से पहले तक। OAuthClientCredentialsTokenResolver उन घटकों की ओर से क्लाइंट क्रेडेंशियल्स ग्रांट के माध्यम से OAuth 2.0 बियरर टोकन प्राप्त करता है जो एक नामित OAuth प्रोफ़ाइल के साथ अपनी आउटबाउंड कॉल्स को प्रमाणित करते हैं, जैसे कि camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat और IBM watsonx घटक, और वे एप्लिकेशन जो सीधे OAuthClientAuthenticationFactory SPI को कॉल करते हैं। यह प्राप्त किए गए टोकन को एक स्टैटिक कैश में रखता था जो JVM में प्रत्येक रिज़ॉल्वर इंस्टेंस और प्रत्येक CamelContext द्वारा साझा किया जाता था, और उस कैश को केवल टोकन एंडपॉइंट और क्लाइंट ID पर कुंजीबद्ध करता था, हालाँकि टोकन अनुरोध में क्लाइंट सीक्रेट और अनुरोधित स्कोप भी होता है। इसलिए दो प्रोफ़ाइल जो एक ही टोकन एंडपॉइंट और क्लाइंट ID साझा करते हैं लेकिन भिन्न स्कोप का अनुरोध करते हैं, या भिन्न क्लाइंट सीक्रेट के साथ प्रमाणित करते हैं, एक ही कैश प्रविष्टि पर मैप हो जाते थे: जिस प्रोफ़ाइल ने पहले टोकन रिज़ॉल्व किया वह प्रविष्टि को भरता था, और फिर दूसरे प्रोफ़ाइल को वही टोकन दे दिया जाता था, उसके अपने कॉन्फ़िगरेशन के अंतर्गत कोई टोकन अनुरोध किए बिना, जब तक टोकन वैध रहता। टोकन कैशिंग डिफ़ॉल्ट रूप से सक्षम है, और कई प्रोफ़ाइल को एक ही आइडेंटिटी प्रोवाइडर क्लाइंट पर इंगित करना प्रोफ़ाइल समर्थन का एक सामान्य उपयोग है, न कि किसी असुरक्षित सेटिंग का ऑप्ट-इन। परिणाम एक आउटबाउंड अनुरोध है जो किसी अन्य प्रोफ़ाइल के स्कोप के लिए जारी किया गया टोकन ले जाता है, जो कॉलिंग प्रोफ़ाइल के लिए कॉन्फ़िगर किए गए अधिकार से अधिक व्यापक अधिकार प्रदान कर सकता है, या ऐसी सेवा तक पहुँच सकता है जिसके लिए टोकन जारी नहीं किया गया था; उन आइडेंटिटी प्रोवाइडर के साथ जो टोकन के ऑडियंस को अनुरोधित स्कोप से प्राप्त करते हैं, एक भिन्न स्कोप का अर्थ पूरी तरह से भिन्न सेवा के लिए टोकन हो सकता है। भिन्न क्लाइंट सीक्रेट के साथ कॉन्फ़िगर किए गए प्रोफ़ाइल को भी उसी तरह दूसरे सीक्रेट के साथ प्राप्त टोकन परोसा जाता था, बिना अपने स्वयं के सीक्रेट के साथ प्रमाणित किए। प्रोफ़ाइल डिप्लॉयमेंट द्वारा कॉन्फ़िगर किए जाते हैं, जो विश्वसनीय है, इसलिए कोई भी अविश्वसनीय इनपुट कैश तक नहीं पहुँचता: लाभ पाने वाला पक्ष वह सेवा है जिसे ऐसा टोकन प्राप्त होता है जो उसके लिए अभिप्रेत नहीं था, जो यदि शत्रुतापूर्ण या समझौता किया गया हो, तो उस टोकन को उसके स्कोप के भीतर पुनः चला सकती है। इस समस्या तक पहुँचने के लिए ऐसे डिप्लॉयमेंट की आवश्यकता है जो एक ही टोकन एंडपॉइंट और क्लाइंट ID साझा करते हुए स्कोप या क्लाइंट सीक्रेट में भिन्न एक से अधिक प्रोफ़ाइल परिभाषित करता हो। उपयोगकर्ताओं को संस्करण 4.23.0 में अपग्रेड करने की सिफ़ारिश की जाती है, जो इस समस्या को ठीक करता है। यदि उपयोगकर्ता 4.22.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.22.2 में अपग्रेड करने का सुझाव दिया जाता है। 4.19.x से 4.21.x रिलीज़ लाइनें इस समस्या के समाधान से पहले ही जीवन-चक्र के अंत तक पहुँच चुकी थीं और उन्हें कोई फ़िक्स प्राप्त नहीं होगा, इसलिए उन पर चल रहे डिप्लॉयमेंट को किसी समर्थित रिलीज़ पर स्थानांतरित होना चाहिए। उन डिप्लॉयमेंट के लिए जो तुरंत अपग्रेड नहीं कर सकते, प्रत्येक OAuth प्रोफ़ाइल पर टोकन कैशिंग अक्षम करें जो किसी अन्य प्रोफ़ाइल के साथ टोकन एंडपॉइंट और क्लाइंट ID साझा करता है, किसी नामित प्रोफ़ाइल के लिए `camel.oauth.NAME.cache-tokens=false` और डिफ़ॉल्ट प्रोफ़ाइल के लिए `camel.oauth.cache-tokens=false` सेट करके, ताकि प्रत्येक रिज़ॉल्यूशन उस प्रोफ़ाइल के अपने स्कोप और क्लाइंट सीक्रेट के साथ टोकन का अनुरोध करे, प्रत्येक रिज़ॉल्यूशन पर एक टोकन अनुरोध की कीमत पर। वैकल्पिक रूप से, प्रत्येक प्रोफ़ाइल के लिए आइडेंटिटी प्रोवाइडर पर एक अलग क्लाइंट पंजीकृत करें जिसे भिन्न स्कोप या क्लाइंट सीक्रेट की आवश्यकता होती है, ताकि ऐसी कोई भी दो प्रोफ़ाइल एक ही क्लाइंट ID साझा न करें।