CVE-2026-66908

सारांश

Apache Camel Platform HTTP Main कंपोनेंट में अनुचित प्रमाणीकरण (Improper Authentication) भेद्यता। यह समस्या Apache Camel के इन संस्करणों को प्रभावित करती है: 4.8.0 से 4.22.0 से पहले तक। camel-main एम्बेडेड HTTP सर्वर अपने एंडपॉइंट्स को JWT प्रमाणीकरण से सुरक्षित कर सकता है, जिसे authenticationEnabled के साथ JWT कीस्टोर प्रॉपर्टीज़ के द्वारा कॉन्फ़िगर किया जाता है। JWTAuthenticationConfigurer.buildJwtOptions ने null लौटाया जब न तो jwtIssuer और न ही jwtAudience कॉन्फ़िगर किया गया था, और कॉलर ने तब JWTAuthOptions.setJWTOptions कॉल को पूरी तरह से छोड़ दिया, जिससे Vert.x JWTAuth इंस्टेंस केवल कीस्टोर से बनाया गया। परिणाम यह हुआ कि इनबाउंड टोकनों की जाँच केवल हस्ताक्षर (signature) और समाप्ति (expiry) के लिए की गई: iss और aud क्लेम बिल्कुल भी सत्यापित नहीं किए गए। किसी भी चीज़ ने यह संकेत नहीं दिया - सर्वर सामान्य रूप से शुरू हुआ और कोई चेतावनी नहीं दी - इसलिए दस्तावेज़ित तरीके से कॉन्फ़िगर की गई डिप्लॉयमेंट ने चुपचाप उससे कम सुरक्षा लागू की जितनी ऑपरेटर ने सक्षम की थी, और कंपोनेंट दस्तावेज़ीकरण ने स्वयं हस्ताक्षर और समाप्ति जाँच को डिफ़ॉल्ट के रूप में प्रस्तुत किया, जिसमें issuer और audience वैकल्पिक अतिरिक्त के रूप में थे। एप्लिकेशन सर्वर और मैनेजमेंट सर्वर दोनों प्रभावित हुए, क्योंकि यह चूक दोनों configureAuthentication पथों में से प्रत्येक में थी। इसलिए, कॉन्फ़िगर किए गए कीस्टोर द्वारा विश्वसनीय किसी भी कुंजी से हस्ताक्षरित कोई भी अवधि-असमाप्त टोकन स्वीकार कर लिया गया, चाहे उसे किसी भी issuer ने जारी किया हो या वह किसी भी audience के लिए अभिप्रेत हो। यह कितनी दूर तक पहुँचता है यह कीस्टोर के ट्रस्ट सेट पर निर्भर करता है: जहाँ हस्ताक्षर कुंजी किसी साझा या मल्टी-टेनेंट आइडेंटिटी प्रोवाइडर की होती है, वहाँ पूरी तरह से भिन्न audience के लिए वैध रूप से जारी किया गया टोकन स्वीकार कर लिया जाता है, जबकि समर्पित साइनर रखने वाला कीस्टोर इसे उसी ट्रस्ट डोमेन के भीतर अन्य सेवाओं के लिए जारी किए गए टोकनों के पुन: उपयोग तक सीमित कर देता है। jwtIssuer और jwtAudience विकल्प 4.21.0 से पहले मौजूद नहीं थे, इसलिए पुराने रिलीज़ों पर इन क्लेमों को लागू कराने का कोई समर्थित तरीका ही नहीं था। उपयोगकर्ताओं को संस्करण 4.22.0 में अपग्रेड करने की अनुशंसा की जाती है, जो इस समस्या को ठीक करता है। 4.22.0 से, सर्वर तब शुरू होने से इनकार कर देता है जब JWT कीस्टोर कॉन्फ़िगर किया गया हो लेकिन न तो jwtIssuer और न ही jwtAudience सेट किया गया हो, और वह इसमें शामिल प्रॉपर्टीज़ के नाम बताता है। एक डिप्लॉयमेंट जो वास्तव में केवल हस्ताक्षर और समाप्ति सत्यापन चाहता है, उसे नए jwtAllowMissingIssuerAndAudience विकल्प के साथ स्पष्ट रूप से ऐसा कहना होगा, जो डिफ़ॉल्ट रूप से false होता है। यह व्यवहार केवल 4.22.0 पर ठीक किया गया है। 4.14.9 और 4.18.4 रिलीज़ डिफ़ॉल्ट नहीं बदलतीं: वे jwtIssuer और jwtAudience विकल्प जोड़ती हैं ताकि उन मेंटेनेंस लाइनों पर ऑपरेटर कॉन्फ़िगरेशन द्वारा क्लेम लागू कर सकें, और एक इंस्टॉलेशन जो उन दो प्रॉपर्टीज़ में से कम से कम एक को सेट किए बिना 4.14.9 या 4.18.4 में अपग्रेड होता है, वह अभी भी विश्वसनीय कुंजी द्वारा हस्ताक्षरित किसी भी अवधि-असमाप्त टोकन को स्वीकार कर रहा है। इसलिए 4.14.x या 4.18.x पर उपयोगकर्ताओं को 4.14.9 या 4.18.4 में अपग्रेड करना चाहिए और फिर jwtIssuer, jwtAudience, या दोनों सेट करना चाहिए। 4.8.0 से 4.21.x तक (4.21.x सहित) के रिलीज़ इन क्लेमों को लागू करने का कोई तरीका प्रदान नहीं करते और उन्हें ऐसे संस्करण में स्थानांतरित किया जाना चाहिए जो ऐसा करता हो। संस्करण से स्वतंत्र रूप से, JWT कीस्टोर को सबसे छोटे संभव ट्रस्ट सेट तक सीमित रखें - आदर्श रूप से किसी साझा आइडेंटिटी-प्रोवाइडर कुंजी के बजाय इस सेवा के लिए समर्पित साइनर - और जहाँ गेटवे पहले से ही सर्वर के सामने issuer और audience की वैधता सत्यापित करता है, सुनिश्चित करें कि उसे बायपास नहीं किया जा सके। नोट: JIRA टिकट: https://issues.apache.org/jira/browse/CAMEL-24281 उन विभिन्न कमिट्स को संदर्भित करता है जिन्होंने समस्या का समाधान किया, और इसमें अधिक विवरण हैं। फेल-क्लोज़्ड (fail-closed) गार्ड को बैकपोर्ट नहीं किया जा सका। jwtIssuer और jwtAudience विकल्प स्वयं केवल 4.21.0 में CAMEL-23525 द्वारा पेश किए गए थे, इसलिए camel-4.18.x और camel-4.14.x पर ऑपरेटर के पास आवश्यकता को पूरा करने के लिए सेट करने योग्य कुछ भी नहीं था, और यह गार्ड उन ब्रांचों पर हर JWT डिप्लॉयमेंट को बिना किसी उपलब्ध समाधान के तोड़ देता।