CVE-2026-78329

Beschreibung

Fehlerhafte Sicherheitsanfälligkeit für die Eingabevalidierung in der Apache Camel Undertow-Komponente. Dieses Problem betrifft Apache Camel: von 4.11.0 vor 4.14.9, von 4.15.0 vor 4.18.4, von 4.19.0 vor 4.22.0. UndertowEndpoint hat sein HeaderFilterStrategy-Feld standardmäßig auf die Basis HttpHeaderFilterStrategy gesetzt und diese Instanz in das UndertowHttpBinding geschoben, das es faul erstellt, und die UndertowHeaderFilterStrategy überschrieben, die DefaultUndertowHttpBinding in seinem eigenen Konstruktor installiert. Sofern ein Deployment keine benutzerdefinierte Bindung oder eine explizite HeaderFilterStrategy lieferte, wurde die undertow-spezifische Filterung daher nie auf endpunktkonfigurierten Routen ausgeführt: Das Strategieobjekt wurde erstellt und sofort ersetzt, bevor es konsultiert werden konnte. Die Folge ist, dass das Legacy Websocket. Exchange-Header-Präfix wurde nicht an der Undertow-Transportgrenze in beiden Richtungen gefiltert, so dass ein Undertow-HTTP-Verbraucher eingehende Draht-Header dieses Formulars auf die Exchange abgebildet hat, wo ein Undertow-WebSocket-Produzent sie als Versandrichtlinien liest und dazu gebracht werden kann, sie an einen anderen Peer als den zu liefern, den die Route ausgewählt hat; und Header-Namen, die Undertow selbst nicht akzeptiert, wurden auf die Exchange abgebildet, anstatt übersprungen zu werden. Ruhende DSL-Konsumenten waren nie betroffen, da UndertowComponent UndertowRestHeaderFilterStrategy explizit zuweist, was die Undertow-Strategie erweitert. Dies ist keine Regression von CVE-2025-30177: Die Basis-HttpHeaderFilterStrategy konfiguriert den eingehenden Camel-Präfix-Filter selbst, so dass der durch diese Empfehlung eingeführte Schutz weiterhin durch die Basisklasse funktionierte und nie verloren ging. Was die Änderung tat, war, die Undertow-Strategie auf dem Endpunktpfad verwaist zu lassen, mit dem Effekt, dass zwei nachfolgende Korrekturen hineingeschrieben wurden - eine überspringende Kopfzeilennamen unter dem Schlepper, eine Filterung des Legacy-Websockets. Präfix in beiden Richtungen - wurden auf eine Klasse angewendet, die der Endpunkt nicht mehr verwendet hat und in den Releases, die sie ausgeliefert haben, nie wirksam wurde. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, wodurch das Problem behoben wird. Wenn sich Benutzer auf dem 4.14.x LTS-Releases-Stream befinden, wird empfohlen, ein Upgrade auf 4.14.9 durchzuführen. Wenn Benutzer auf dem 4.18.x-Releases-Stream sind, wird empfohlen, ein Upgrade auf 4.18.4 durchzuführen. Für Bereitstellungen, die nicht sofort aktualisiert werden können, konfigurieren Sie die Strategie explizit, anstatt sich auf den Standard zu verlassen, z. B. indem Sie eine UndertowHeaderFilterStrategy in der Registry binden und sie im Endpunkt als undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy referenzieren, und entfernen Sie zusätzlich die Dispatch-Header an der Vertrauensgrenze mit removeHeaders („websocket.*). Beachten Sie eine Restbeschränkung, die das Upgrade nicht entfernt: Die Undertow-Komponente behält das Websocket absichtlich. Werte als Teil seines extern sichtbaren API-Vertrags, und UndertowProducer liest sie mit in.getHeader, das überhaupt keine HeaderFilterStrategy konsultiert. Die wiederhergestellte Filterung ist daher nur Verteidigung in der Tiefe an der Unterschlepptransportgrenze ..

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Apache Software Foundation camel.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.