CVE-2026-59230
Apache Camel: Camel-Mail: headersInline सक्षम के साथ unmarshalling करते समय MimeMultipart डेटा प्रारूप ने बिना हेडर फ़िल्टर रणनीति के MIME हेडर को Camel संदेश पर कॉपी कर दिया
- प्रकाशित
- 24 अग॰ 2026
- अद्यतन
- 25 अग॰ 2026
- सीएनए असाइन करना
- apache
- साक्ष्य देखे गए
- 24 अग॰ 2026
प्राथमिक सीवीएसएस
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:Nकम · अगले 30 दिन
- प्रतिशत
- 35.8%
- मॉडल दिनांक
- 21 सित॰ 2026
ईपीएसएस एक सांख्यिकीय अनुमान है, कोई निश्चितता या प्रभाव का माप नहीं। इसे सीवीएसएस, केईवी स्थिति, एक्सपोज़र और अपने वातावरण के साथ मिलाएं।
सारांश
Apache Camel में अनुचित इनपुट सत्यापन भेद्यता। यह समस्या Apache Camel को प्रभावित करती है: 2.17.0 से 4.14.9 से पहले, 4.15.0 से 4.18.4 से पहले, 4.19.0 से 4.22.0 से पहले। camel-mail घटक एक MimeMultipart डेटा प्रारूप के साथ आता है जो MIME मल्टीपार्ट संदेश को unmarshal कर सकता है। जब इसे headersInline को true पर सेट करके कॉन्फ़िगर किया जाता है, तो unmarshal पथ आने वाले संदेश के MIME हेडर को Camel संदेश पर कॉपी करता है: यह हर उस हेडर की गणना करता है जो उन तीन मानक हेडरों में से नहीं है जिन्हें यह स्वयं उत्पन्न करता है - Message-ID, MIME-Version और Content-Type - और प्रत्येक के लिए setHeader कॉल करता है, बिना किसी HeaderFilterStrategy लागू किए। उन MIME हेडरों के नाम unmarshal किए जा रहे संदेश से आते हैं, इसलिए कोई प्रेषक जो संदेश को प्रभावित कर सकता है, वह ऐसा हेडर रख सकता है जिसका नाम Camel-आंतरिक नामस्थान में आता है और उसे Exchange पर सेट करवा सकता है। Camel घटक उस नामस्थान से नियंत्रण हेडर पढ़कर अपने कॉन्फ़िगर किए गए व्यवहार को ओवरराइड करते हैं - उदाहरण के लिए, camel-sql प्रोड्यूसर, जब कोई Camel हेडर मौजूद होता है तो निष्पादित करने के लिए स्टेटमेंट उसी से लेता है - इसलिए एक इंजेक्ट किया गया हेडर यह बदल सकता है कि रूट में आगे का कोई चरण डेटा के साथ क्या करता है, जिसे रूट लेखक ने कभी संदेश से लेने का इरादा नहीं किया था। कौन से sinks पहुंच योग्य हैं, और परिणाम क्या हैं, यह पूरी तरह से इस पर निर्भर करता है कि रूट unmarshal चरण के बाद क्या करता है। camel-mail उपभोक्ता ने पहले से ही अपने स्वयं के इनबाउंड पथ पर एक हेडर फ़िल्टर रणनीति लागू कर दी थी, इसलिए यह उसी घटक में समानांतर इनबाउंड पथ था जिसे पहले के सख्तीकरण (hardening) ने कवर नहीं किया था। प्रभावित कॉपी केवल तभी पहुंची जाती है जब headersInline सक्षम होता है, जो डिफ़ॉल्ट नहीं है: डिफ़ॉल्ट सेटिंग के साथ MIME हेडर संदेश हेडर के रूप में नहीं, बल्कि अनुलग्नकों (attachments) के रूप में सामने आते हैं, और प्रभावित नहीं होते हैं। यह व्यवहार 2.17.0 में डेटा प्रारूप की शुरुआत से चला आ रहा है और इस सुधार तक हर रिलीज़ लाइन पर मौजूद था। उपयोगकर्ताओं को संस्करण 4.22.0 में अपग्रेड करने की अनुशंसा की जाती है, जो इस समस्या को ठीक करता है। यदि उपयोगकर्ता 4.14.x LTS रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.14.9 में अपग्रेड करने का सुझाव दिया जाता है। यदि उपयोगकर्ता 4.18.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.18.4 में अपग्रेड करने का सुझाव दिया जाता है। उन परिनियोजनों (deployments) के लिए जो तुरंत अपग्रेड नहीं कर सकते, जहां इनलाइन हेडर की आवश्यकता नहीं है, वहां headersInline को उसके डिफ़ॉल्ट false पर छोड़ दें, क्योंकि कॉपी केवल तभी पहुंची जाती है जब यह सक्षम हो। जहां इसे सक्षम रखना आवश्यक हो, वहां unmarshal चरण के तुरंत बाद Camel-आंतरिक हेडर हटा दें, उदाहरण के लिए removeHeaders(“Camel*”) को किसी भी प्रोसेसर या प्रोड्यूसर से पहले रखें जो नियंत्रण हेडर पढ़ता है, और अविश्वसनीय प्रेषक से MIME सामग्री को ऐसे रूट में unmarshal न करें जो हेडर मानों पर डिस्पैच करता हो। गहराई में सुरक्षा (defence in depth) के रूप में, विश्वास सीमा (trust boundary) के बाहर से आने वाले किसी भी MIME संदेश के हेडर नामों को अविश्वसनीय इनपुट मानें।
जिम्मेदारीपूर्ण उपयोग
भेद्यता जानकारी का उपयोग केवल उन प्रणालियों पर करें जिनके मालिक आप हैं या परीक्षण के लिए अधिकृत हैं। किटप्लॉइट सार्वजनिक अनुसंधान मेटाडेटा से लिंक करता है और शोषण कोड या दुर्भावनापूर्ण पेलोड को संग्रहीत नहीं करता है।