CVE-2026-79986 — camel-azure-files: consumer, शेयर लिस्टिंग से बिना containment के रिमोट पाथ बनाता है

Apache Camel भेद्यता के लिए रीप्रोड्यूसर रिपॉज़िटरी, जिसमें azure-files consumer — जो अन्य रिमोट-फ़ाइल consumers के समान RemoteFileConsumer बेस क्लास से व्युत्पन्न होता है और एक साधारण concatenation हेल्पर के माध्यम से रिमोट पाथ बनाता है — प्रत्येक polled फ़ाइल का रिमोट पाथ कॉन्फ़िगर की गई डायरेक्टरी को Azure File शेयर लिस्टिंग में रिपोर्ट किए गए नाम के साथ जोड़कर बनाता है, बिना किसी containment जाँच के। इसलिए एक लिस्टिंग नाम जो एकल पाथ सेगमेंट नहीं है, retrieval के लिए polled डायरेक्टरी के बाहर resolve हो जाता था और, delete/move/preMove/moveFailed/readLock=rename के साथ, deletion या rename भी हो जाता था।

यह रीप्रोड्यूसर केवल-लेखक (author-only) है — नीचे देखें — और यह runnable CVE-2026-79983 (camel-ftp) और CVE-2026-79984 (camel-mina-sftp) का Azure-Files सहोदर है, जो एक embedded दुर्भावनापूर्ण सर्वर के विरुद्ध end to end समान मूल कारण और समाधान प्रदर्शित करते हैं।

केवल-लेखक क्यों

1. जैसा कि advisory में कहा गया है, इस मुद्दे तक पहुँचने के लिए "एक लिस्टिंग नाम आवश्यक है जो एकल पाथ सेगमेंट नहीं है, जिसे Azure Files REST सेवा सामान्यतः नहीं लौटाती; इस exposure को इस स्कीम के विरुद्ध प्रदर्शित proof of concept के बजाय अन्य रिमोट-फ़ाइल consumers के समान आधार पर ठीक किया गया था।"
2. एक लाइव रन के लिए अतिरिक्त रूप से एक वास्तविक Azure Storage खाता और File शेयर आवश्यक है।

इसलिए यह रिपॉज़िटरी सटीक प्रभावित consumer वायरिंग रखती है (एक वास्तविक camel-azure-files रूट, देखें AzureFilesRoute.java / AzureFilesRoutes.java), तंत्र और समाधान का दस्तावेज़ीकरण करती है, और runnable end-to-end प्रदर्शन को ऊपर दिए गए FTP और SFTP रीप्रोड्यूसर्स को सौंपती है।

रनटाइम	डायरेक्टरी	स्टैक
Camel Spring Boot	camel-spring-boot/	Spring Boot 3.5.13 + camel-azure-files 4.22.0 (प्रभावित; 4.22.1 में ठीक)
Camel Quarkus	camel-quarkus/	Quarkus 3.29.0 + camel-quarkus-azure-files 3.29.0 (Camel 4.15.0, प्रभावित)

दोनों मॉड्यूल Azure क्रेडेंशियल्स के बिना साफ़ रूप से compile और start होते हैं (रूट autoStartup=false के साथ परिभाषित है)। सटीक प्रभावित रूट को अपने स्वयं के Azure File शेयर की ओर इंगित करने के लिए az.account/az.share/az.sharedKey के साथ -Daz.enabled=true सेट करें।

cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack   # prints the explanation + links to the runnable PoCs
docker compose down

भेद्यता सारांश

गुण	मान
घटक	camel-azure-files (azure-files स्कीम)
CWE	CWE-22 (किसी पथनाम का प्रतिबंधित निर्देशिका तक अनुचित सीमन)
गंभीरता	उच्च
आक्रमण वेक्टर	एक शेयर-लिस्टिंग नाम (सर्वर-प्रदत्त) जो एकल पथ खंड नहीं है
प्रभाव	पढ़ना — और, delete/move/readLock=rename के साथ, हटाना या नाम बदलना — एंडपॉइंट की क्रेडेंशियल्स का उपयोग करते हुए, पोल की गई निर्देशिका के बाहर की फ़ाइलें
प्रभावित संस्करण	4.0.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक
ठीक किए गए संस्करण	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24487
श्रेय	NSSL, SJTU से Dilrevx

सलाह: https://camel.apache.org/security/CVE-2026-79986.html

समाधान

azure-files उपभोक्ता अब अन्य रिमोट-फ़ाइल उपभोक्ताओं के समान कंटेनमेंट जाँच लागू करता है: एक हल किया गया पथ जो पोल की गई निर्देशिका के बाहर आता है, उसे चेतावनी के साथ छोड़ दिया जाता है, इसलिए ट्रैवर्सल खंडों वाला लिस्टिंग नाम अब retrieve/delete/rename ऑपरेंड तक नहीं पहुँचता।

यदि आप अपग्रेड नहीं कर सकते तो शमन

उपभोक्ता को filter/antInclude/include के साथ सीमित करें ताकि केवल एकल-खंड नाम स्वीकार किए जाएँ, और उन शेयरों के विरुद्ध delete/move/preMove/moveFailed/readLock=rename से बचें जिनकी लिस्टिंग पूरी तरह विश्वसनीय नहीं है।

अस्वीकरण

यह रिपॉज़िटरी शैक्षिक और रक्षात्मक उद्देश्यों के लिए प्रकाशित की गई है: Apache Camel उपयोगकर्ताओं को भेद्यता को समझने, यह सत्यापित करने में मदद करने के लिए कि क्या वे प्रभावित हैं, और पुष्टि करने के लिए कि अपग्रेड करने से यह हल हो जाती है। इस सामग्री का उपयोग उन सिस्टमों के विरुद्ध न करें जिनके आप स्वामी या संचालक नहीं हैं।