CVE-2026-78329

सारांश

Apache Camel Undertow घटक में अनुचित इनपुट सत्यापन भेद्यता। यह मुद्दा Apache Camel को प्रभावित करता है: 4.11.0 से 4.14.9 से पहले तक, 4.15.0 से 4.18.4 से पहले तक, 4.19.0 से 4.22.0 से पहले तक। UndertowEndpoint ने अपने headerFilterStrategy फ़ील्ड को आधार HttpHeaderFilterStrategy पर डिफ़ॉल्ट किया और उस उदाहरण को UndertowHttpBinding में धकेल दिया जिसे यह lazily बनाता है, जिससे DefaultUndertowHttpBinding अपने कंस्ट्रक्टर में स्थापित करने वाले UndertowHeaderFilterStrategy को अधिलेखित कर दिया। जब तक किसी डिप्लॉयमेंट ने कस्टम binding या स्पष्ट headerFilterStrategy प्रदान नहीं किया, undertow-विशिष्ट फ़िल्टरिंग इसलिए endpoint-कॉन्फ़िगर रूट्स पर कभी निष्पादित नहीं हुई: स्ट्रेटेजी ऑब्जेक्ट बनाया गया और उसे परामर्श देने से पहले तुरंत बदल दिया गया। परिणाम यह है कि लीगेसी websocket. Exchange-header उपसर्ग को undertow परिवहन सीमा पर किसी भी दिशा में फ़िल्टर नहीं किया गया था, इसलिए एक undertow HTTP उपभोक्ता ने उस रूप के इनबाउंड वायर हेडर को Exchange पर मैप किया, जहाँ एक undertow WebSocket निर्माता उन्हें डिस्पैच निर्देशों के रूप में पढ़ता है और उसे रूट द्वारा चुने गए पीयर के अलावा किसी अन्य पीयर को वितरित करने के लिए बनाया जा सकता है; और हेडर नाम जिन्हें undertow स्वयं स्वीकार नहीं करता है, उन्हें छोड़ने के बजाय Exchange पर मैप किया गया था। Rest DSL उपभोक्ता कभी प्रभावित नहीं हुए, क्योंकि UndertowComponent स्पष्ट रूप से UndertowRestHeaderFilterStrategy निर्दिष्ट करता है, जो undertow रणनीति का विस्तार करता है। यह CVE-2025-30177 का प्रतिगमन नहीं है: आधार HttpHeaderFilterStrategy इनबाउंड Camel-उपसर्ग फ़िल्टर को स्वयं कॉन्फ़िगर करता है, इसलिए उस सलाह द्वारा शुरू की गई सुरक्षा आधार वर्ग के माध्यम से काम करती रही और कभी खोई नहीं। परिवर्तन ने जो किया वह undertow रणनीति को endpoint पथ पर अनाथ छोड़ दिया, जिसके प्रभाव से उसमें लिखे गए दो बाद के सुधार - एक undertow द्वारा अस्वीकृत हेडर नामों को छोड़ना, एक दोनों दिशाओं में लीगेसी websocket. उपसर्ग को फ़िल्टर करना - एक ऐसी कक्षा पर लागू किए गए जिसका endpoint अब उपयोग नहीं करता था और जिन रिलीज़ों में वे भेजे गए थे उनमें कभी प्रभावी नहीं हुए। उपयोगकर्ताओं को संस्करण 4.22.0 में अपग्रेड करने की सलाह दी जाती है, जो मुद्दे को ठीक करता है। यदि उपयोगकर्ता 4.14.x LTS रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.14.9 में अपग्रेड करने का सुझाव दिया जाता है। यदि उपयोगकर्ता 4.18.x रिलीज़ स्ट्रीम पर हैं, तो उन्हें 4.18.4 में अपग्रेड करने का सुझाव दिया जाता है। उन डिप्लॉयमेंट्स के लिए जो तुरंत अपग्रेड नहीं कर सकते हैं, डिफ़ॉल्ट पर भरोसा करने के बजाय रणनीति को स्पष्ट रूप से कॉन्फ़िगर करें, उदाहरण के लिए रजिस्ट्री में UndertowHeaderFilterStrategy बांधकर और endpoint पर undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy के रूप में संदर्भित करके, और अतिरिक्त रूप से removeHeaders(“websocket.*”) के साथ विश्वास सीमा पर डिस्पैच हेडर हटा दें। ध्यान दें कि एक शेष सीमा है जिसे अपग्रेड करना दूर नहीं करता है: undertow घटक जानबूझकर websocket. मानों को अपने बाहरी रूप से दृश्यमान API अनुबंध के हिस्से के रूप में रखता है, और UndertowProducer उन्हें in.getHeader के साथ पढ़ता है, जो किसी HeaderFilterStrategy से परामर्श नहीं करता है। इसलिए बहाल की गई फ़िल्टरिंग केवल undertow परिवहन सीमा पर गहराई से सुरक्षा है। एक रूट जो किसी गैर-undertow उपभोक्ता से अविश्वसनीय संदेश को undertow निर्माता में ले जाता है, इस फिक्स द्वारा सुरक्षित नहीं है और उसे उन हेडरों को स्वयं हटाना होगा।