CVE-2026-79986

सारांश

Apache Camel Azure Files घटक में एक Pathname को प्रतिबंधित निर्देशिका तक सीमित करने में अनुचित सीमा ('Path Traversal') की भेद्यता है। यह समस्या Apache Camel को प्रभावित करती है: 4.0.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक। Camel के remote-file consumers किसी दूरस्थ सर्वर पर एक निर्देशिका को poll करते हैं और प्रत्येक फ़ाइल का पूर्ण दूरस्थ पथ, कॉन्फ़िगर की गई निर्देशिका को सर्वर की निर्देशिका लिस्टिंग में बताए गए फ़ाइल नाम के साथ जोड़कर बनाते हैं। उस संयोजन (FtpUtils.absoluteFilePath और GenericFileConsumer) में कोई lexical normalization नहीं लागू किया गया था और न ही यह जाँच की गई थी कि परिणाम उस निर्देशिका के भीतर ही रहा जिसे poll किया जा रहा था, और परिणामी पथ फ़ाइल पर प्रत्येक आगामी दूरस्थ ऑपरेशन के लिए operand बन गया: retrieval (FtpOperations.retrieveFile / SftpOperations, जिस तक GenericFileConsumer से पहुँचा जाता है जहाँ retrieve नाम सीधे GenericFile.getAbsoluteFilePath से लिया जाता है), delete=true होने पर deletion (GenericFileDeleteProcessStrategy), और move, preMove, moveFailed या readLock=rename कॉन्फ़िगर होने पर renaming (GenericFileProcessStrategySupport और GenericFileRenameExclusiveReadLockStrategy)। न तो isValidFile और न ही isMatched ने कोई containment जाँच की। इसलिए एक लिस्टिंग प्रविष्टि जो एकल path segment नहीं है, कॉन्फ़िगर की गई polling निर्देशिका के बाहर के पथ पर resolve हो गई, जिससे Camel ने endpoint के अपने credentials का उपयोग करके उसके बाहर की फ़ाइलों को पढ़ा, हटाया या उनका नाम बदला। लिस्टिंग नाम route-नियंत्रित डेटा नहीं है। यह दूरस्थ सर्वर द्वारा प्रदान किया जाता है, और FTP control channel में कोई integrity protection नहीं है, इसलिए एक on-path attacker बिना कोई credentials रखे LIST प्रतिक्रिया को फिर से लिख सकता है; एक समझौता किया गया, दुर्भावनापूर्ण या multi-tenant सर्वर, या virtual filesystem द्वारा समर्थित सर्वर, ऐसा नाम सीधे उत्सर्जित कर सकता है। Retrieval डिफ़ॉल्ट consumer कॉन्फ़िगरेशन में पहुँच योग्य है, क्योंकि remote consumers हर सूचीबद्ध फ़ाइल को डाउनलोड करते हैं; deletion और renaming के लिए अतिरिक्त रूप से उपरोक्त में से एक disposition विकल्प आवश्यक है, जो सभी सामान्य हैं। उस निर्देशिका से बाहर निकलना जिसे poll करने के लिए Camel कॉन्फ़िगर किया गया था, बिना शर्त है, जबकि सर्वर के अपने account boundary से बाहर निकलना अतिरिक्त रूप से इस पर निर्भर करता है कि वह सर्वर उस account को सीमित करता है या नहीं। jailStartingDirectory विकल्प, जिसे Camel को starting directory तक सीमित करने के रूप में प्रलेखित किया गया है और जो डिफ़ॉल्ट रूप से सक्षम है, producer writes को नियंत्रित करता था और, localWorkDirectory containment कार्य के बाद से, consumer downloads को local work directory तक - लेकिन इसने इस दूरस्थ operand को सीमित नहीं किया, इसलिए इसके नाम और विवरण ने एक ऐसी सीमा का दावा किया जो यहाँ लागू नहीं थी। वही entry point स्थानीय पक्ष पर पहले ही पहचाना जा चुका था: localWorkDirectory download पथ को इस प्रकार सीमित किया गया था कि parent-directory segments वाला दूरस्थ फ़ाइल नाम local work directory के बाहर resolve न हो सके। दूरस्थ operand उस सतह का शेष आधा भाग था। यह artifact azure-files scheme प्रदान करता है। इसका consumer उसी RemoteFileConsumer base class से व्युत्पन्न होता है और एक साधारण concatenation helper के माध्यम से दूरस्थ पथ की रचना करता था, इसलिए इसे वही अप्रतिबंधित resolution विरासत में मिली। इस तक पहुँचने के लिए एक ऐसा लिस्टिंग नाम आवश्यक है जो एकल path segment न हो, जिसे Azure Files REST सेवा सामान्यतः नहीं लौटाती; exposure को इस scheme के विरुद्ध प्रदर्शित proof of concept के बजाय अन्य remote-file consumers के समान आधार पर ठीक किया गया था। Apache Camel 4.23.0 में अपग्रेड करें, जो इस समस्या को ठीक करता है। 4.22.x रिलीज़ स्ट्रीम पर उपयोगकर्ताओं को 4.22.1 में अपग्रेड करना चाहिए। 4.18.x LTS रिलीज़ स्ट्रीम पर उपयोगकर्ताओं को 4.18.5 में अपग्रेड करना चाहिए। 4.14.x स्ट्रीम end of life तक पहुँच चुकी है और इसे यह fix नहीं मिलता; इस पर उपयोगकर्ताओं को किसी समर्थित रिलीज़ स्ट्रीम पर स्थानांतरित होना चाहिए।