
Apache Camel camel-docling में CVE-2026-78163 के लिए रन करने योग्य प्रूफ-ऑफ-कॉन्सेप्ट रिप्रोड्यूसर, जो अवैध String body इनपुट के माध्यम से SSRF और स्थानीय फ़ाइल प्रकटीकरण का प्रदर्शन करता है, साथ में फिक्स्ड-बिल्ड नियंत्रण भी।
Apache Camel की उस भेद्यता के लिए चलाने योग्य proof-of-concept reproducer, जहाँ DoclingProducer यह तय करता था कि
String संदेश body का क्या अर्थ है, उसके prefix का निरीक्षण करके:
http:// या https:// से शुरू होने वाली body को Docling को फ़ेच करने के लिए रिमोट URL के रूप में सौंपा जाता था (SSRF), और/ से शुरू होने वाली (या जिसमें backslash हो) body को स्थानीय फ़ाइलसिस्टम से पढ़ा जाता था (फ़ाइल प्रकटीकरण)।मोड का चयन अंतर्निहित रूप से होता था, किसी एकल व्याख्या को निर्धारित करने के लिए कोई endpoint विकल्प नहीं था, और — Camel
header namespace के विपरीत — संदेश body को कभी भी HeaderFilterStrategy द्वारा फ़िल्टर नहीं किया जाता। इसलिए एक route जिसका अर्थ
"body में जो भी टेक्स्ट आए उसे कन्वर्ट करो" होता है, चुपचाप रिमोट संसाधनों का फ़ेचर या स्थानीय
फ़ाइलों का पाठक बन जाता था, जब भी हमलावर-नियंत्रित टेक्स्ट उन prefix में से किसी एक से शुरू होता।
| Runtime | Directory | Stack | दर्शाता है |
|---|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-docling 4.22.0 (प्रभावित; 4.22.1 में ठीक किया गया) | SSRF और फ़ाइल प्रकटीकरण, साथ ही fixed-build नियंत्रण |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-docling 3.29.0 (Camel 4.15.0, प्रभावित) | केवल फ़ाइल प्रकटीकरण (नोट देखें) |
संस्करण कवरेज। स्थानीय फ़ाइल-प्रकटीकरण sink 4.15.0 में camel-docling की शुरुआत के बाद से मौजूद है; रिमोट-URL sink 4.16.0 में docling-serve समर्थन के साथ जोड़ा गया था। नवीनतम Camel Quarkus (3.29.0) में Camel 4.15.0 बंडल है, इसलिए इसका मॉड्यूल केवल फ़ाइल प्रकटीकरण प्रदर्शित करता है। फ़िक्स Camel 4.18.5 / 4.22.1 / 4.23.0 में आता है; Spring Boot मॉड्यूल प्रभावित build (4.22.0) और fixed build (4.22.1) दोनों चलाता है, इसलिए यह patched व्यवहार भी प्रदर्शित करता है। अभी तक कोई भी जारी Camel Quarkus fixed Camel को बंडल नहीं करता।
किसी भी reproducer को वास्तविक Docling इंस्टॉल की आवश्यकता नहीं है: एक छोटा नकली docling CLI (fake-docling/docling) बाइनरी का
स्थान लेता है और दिखाता है कि वास्तविक बाइनरी producer-प्रदत्त इनपुट के साथ क्या करती — किसी URL को फ़ेच करना, या किसी
फ़ाइल को पढ़ना। यह benign है: यह केवल वही प्रतिध्वनित करता है जिसे प्रोसेस करने के लिए कहा गया था और अपने स्वयं के invocation को लॉग करता है। CVE का मुद्दा यह है
कि हमलावर-प्रदत्त body उस argument तक पहुँचती ही है, बिना किसी opt-in के।
Spring Boot ऐप 127.0.0.1:9099 पर एक केवल-आंतरिक HTTP endpoint भी चलाता है (केवल पोर्ट 8080 प्रकाशित है,
इसलिए कोई बाहरी क्लाइंट 9099 तक सीधे नहीं पहुँच सकता) और एक स्थानीय secret फ़ाइल भी। हमलावर केवल टेक्स्ट भेजता है:
http://127.0.0.1:9099/internal-secret → सर्वर-साइड docling invocation आंतरिक
endpoint को फ़ेच करता है और उसका secret कॉलर को लौटा दिया जाता है।/tmp/cve-2026-78163-secret.txt → स्थानीय फ़ाइल पढ़ी जाती है और लौटाई जाती है।प्रभावित build पर दोनों सफल होते हैं; fixed build पर दोनों को IllegalArgumentException के साथ अस्वीकार कर दिया जाता है
जो उस विकल्प (allowUrlSource / allowFilePathSource) का नाम बताता है जो उन्हें सक्षम करने के लिए आवश्यक होता, और docling
कभी invoke नहीं होता।
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
प्रभावित Spring Boot बिल्ड पर अपेक्षित आउटपुट:
[1] SSRF — sending body = http://127.0.0.1:9099/internal-secret
>>> PROVEN SSRF: the server-side docling invocation fetched the attacker-controlled internal URL.
>>> internal victim saw: [GET /internal-secret]
>>> content returned to the caller:
| INTERNAL-SECRET-DATA (only reachable from inside the deployment)
[2] File disclosure — sending body = /tmp/cve-2026-78163-secret.txt
>>> PROVEN file disclosure: the attacker-named local file was read and returned.
| TOP-SECRET-FILE-CONTENT (local file an attacker should not be able to read)
| Property | Value |
|---|---|
| घटक | camel-docling (camel-docling-starter / camel-quarkus-docling) |
| CWE | CWE-918 (SSRF), CWE-22 (पथ ट्रैवर्सल), CWE-200 (सूचना प्रकटीकरण) |
| गंभीरता | MEDIUM |
| आक्रमण वेक्टर | एक String संदेश निकाय जिसे docling एंडपॉइंट में अग्रेषित किया जाता है, जिसका प्रीफ़िक्स किसी URL-फ़ेच या फ़ाइल-रीड सिंक का चयन करता है; निकाय HeaderFilterStrategy के अधीन नहीं है |
| प्रभाव | आक्रमणकर्ता द्वारा चुने गए URL (आंतरिक सेवाएँ) का सर्वर-साइड फ़ेच और स्थानीय फ़ाइलों का प्रकटीकरण |
| प्रभावित संस्करण | 4.15.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक (फ़ाइल प्रकटीकरण 4.15.0 से; URL सिंक 4.16.0 से) |
| ठीक किए गए संस्करण | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24422 |
| श्रेय | Li Zhiyao (BUPT) |
सलाह: https://camel.apache.org/security/CVE-2026-78163.html
अब एक String निकाय को डिफ़ॉल्ट रूप से स्वयं दस्तावेज़ माना जाता है। दोनों स्थान-पठन विकल्प अब
नए एंडपॉइंट विकल्पों allowUrlSource और allowFilePathSource (दोनों डिफ़ॉल्ट false) के माध्यम से ऑप्ट-इन बन गए हैं; अन्यथा URL
या पथ जैसा दिखने वाला निकाय IllegalArgumentException के साथ अस्वीकार कर दिया जाता है, जिसमें उस विकल्प का नाम होता है जो इसे सक्षम करेगा। एक अतिरिक्त
inputBaseDirectory विकल्प स्थानीय इनपुट पथों को कॉन्फ़िगर की गई निर्देशिका तक सीमित करता है। टाइप्ड निकाय (File, byte[],
InputStream) और CamelDoclingInputFilePath हेडर पहले से ही अपना अर्थ बताते हैं और इन्हें गेट नहीं किया गया है (लेकिन ये
inputBaseDirectory के अधीन रहते हैं)।
बाहरी रूप से उत्पन्न संदेश निकायों को docling एंडपॉइंट में रूट न करें; दस्तावेज़ को टाइप्ड निकाय
(File, byte[], InputStream) या CamelDoclingInputFilePath हेडर के माध्यम से पास करें ताकि निकाय कभी भी प्रीफ़िक्स
व्याख्या के अधीन न हो।
यह रिपॉज़िटरी शैक्षिक और रक्षात्मक उद्देश्यों के लिए प्रकाशित की गई है: Apache Camel उपयोगकर्ताओं को
भेद्यता को समझने, यह सत्यापित करने में मदद करने के लिए कि क्या वे प्रभावित हैं, और पुष्टि करने के लिए कि अपग्रेड करने से यह हल हो जाता है। नकली docling CLI और
"secrets" निष्क्रिय स्थानीय फ़िक्स्चर हैं। इस सामग्री का उपयोग उन सिस्टमों के विरुद्ध न करें जिनके आप स्वामी या संचालक नहीं हैं।