CVE-2026-71569

सारांश

Apache Camel A2A घटक में सर्वर-साइड रिक्वेस्ट फ़ॉर्जरी (SSRF) भेद्यता। यह समस्या Apache Camel को प्रभावित करती है: 4.21.0 से 4.22.2 से पहले तक। WebhookUrlValidator ने पुश नोटिफ़िकेशन वेबहुक होस्ट को दो स्थानों पर वर्गीकृत किया जो एक-दूसरे से मेल नहीं खाते थे। IP लिटरल के रूप में लिखे गए होस्ट को स्ट्रिंग प्रीफ़िक्स की सूची से मिलाया जाता था जो IPv6 यूनिक लोकल रेंज fc00::/7 को नामित करती थी, जबकि नाम के माध्यम से पहुँचे गए होस्ट को रिज़ॉल्व किया जाता था और परिणामी पते को InetAddress प्रेडिकेट्स isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress और isSiteLocalAddress से वर्गीकृत किया जाता था। वे प्रेडिकेट्स प्रीफ़िक्स सूची के समान क्षेत्र को कवर नहीं करते: isSiteLocalAddress पदावनत fec0::/10 ब्लॉक की रिपोर्ट करता है, न कि उसकी जगह लेने वाले fc00::/7 यूनिक लोकल पतों की, और JDK में उनके लिए कोई प्रेडिकेट ही नहीं है। इसलिए वही पता इस बात पर निर्भर करते हुए स्वीकार या अस्वीकार किया जाता था कि वह कैसे लिखा गया था, और एक वेबहुक URL जिसका होस्ट नाम fc00::/7 में रिज़ॉल्व होता था, उस गार्ड को पार कर गया जो लिटरल के रूप में दिए गए समान पते को अस्वीकार करता था। इसके बाद PushNotificationDispatcher ने पुश नोटिफ़िकेशन उस पते पर भेजा, साथ ही उसी कॉन्फ़िगरेशन में मौजूद कोई भी Authorization हेडर भी, जिसकी स्कीम और क्रेडेंशियल्स पंजीकरण करने वाला कॉलर प्रदान करता है। वेबहुक URL पुश नोटिफ़िकेशन पंजीकृत करने वाले कॉलर से TaskPushNotificationConfig.url के रूप में आता है, इसलिए यह हमलावर-नियंत्रित है, और allowLocalWebhookUrls डिफ़ॉल्ट रूप से false है, जो वह कॉन्फ़िगरेशन है जिसमें गार्ड के कायम रहने की अपेक्षा की जाती है। प्रतिक्रिया उस कॉलर को वापस रिले नहीं की जाती जिसने कॉन्फ़िगरेशन पंजीकृत किया था, इसलिए इस अंतराल से जो निकलता है वह Camel प्रक्रिया से एक आंतरिक पते पर एक ब्लाइंड आउटबाउंड HTTPS अनुरोध है जिसे अस्वीकार करने के लिए गार्ड लिखा गया था; उस तरह से किसी सेवा तक पहुँचने के लिए अतिरिक्त रूप से आवश्यक है कि नाम लक्ष्य वातावरण में fc00::/7 में रिज़ॉल्व हो, कि उस पते पर कोई HTTPS सेवा सुन रही हो, और कि अनुरोध किए जा रहे नाम के लिए TLS हैंडशेक सफल हो, यही कारण है कि गंभीरता को मध्यम आँका गया है। वही स्ट्रिंग प्री-चेक दूसरी दिशा में भी गलत था: यह कच्चे होस्ट स्ट्रिंग से मिलान करता था बिना पहले यह स्थापित किए कि होस्ट एक IP लिटरल था, इसलिए केवल fc या fd से शुरू होने वाला कोई भी नाम, जैसे fcm.googleapis.com, सीधे अस्वीकार कर दिया जाता था। उपयोगकर्ताओं को संस्करण 4.23.0 में अपग्रेड करने की सिफ़ारिश की जाती है, जो इस समस्या को ठीक करता है। यदि उपयोगकर्ता 4.22.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.22.2 में अपग्रेड करने का सुझाव दिया जाता है। 4.21.x रिलीज़ लाइन इस समस्या के समाधान से पहले ही जीवन-चक्र के अंत तक पहुँच चुकी थी और उसे कोई फ़िक्स नहीं मिलेगा, इसलिए उस पर तैनातियों को किसी समर्थित रिलीज़ पर स्थानांतरित होना चाहिए। अब लिटरल और रिज़ॉल्व दोनों पथ पते को उसके कच्चे बाइट्स से एक साझा क्लासिफ़ायर के साथ वर्गीकृत करते हैं, जो fc00::/7 और साझा पता स्थान 100.64.0.0/10 को पहचानता है, साथ ही IPv4-संगत, NAT64 (64:ff9b::/96) और 6to4 (2002::/16) पतों को भी जिनका अंतर्निहित IPv4 पता वैश्विक रूप से रूटेबल नहीं है। उन तैनातियों के लिए जो तुरंत अपग्रेड नहीं कर सकते, A2A पुश नोटिफ़िकेशन कॉन्फ़िगरेशन पथ के सामने प्रमाणीकरण रखें ताकि वेबहुक URL किसी अविश्वसनीय कॉलर से न आए, और नेटवर्क स्तर पर Camel प्रक्रिया से fc00::/7 तक ईग्रेस को अस्वीकार करें; जहाँ तैनाती को IPv6 की आवश्यकता नहीं है, वहाँ JVM को -Djava.net.preferIPv4Stack=true के साथ शुरू करने से वह पता वर्ग हट जाता है जिस पर यह अंतराल टिका है। ध्यान दें कि allowLocalWebhookUrls=false पहले से ही डिफ़ॉल्ट है और अपने आप में इस अंतराल को बंद नहीं करता।