CVE-2026-78329

Zusammenfassung

Schwachstelle durch unsachgemäße Eingabevalidierung in der Undertow-Komponente von Apache Camel. 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 setzte sein Feld headerFilterStrategy standardmäßig auf die Basisklasse HttpHeaderFilterStrategy und übergab diese Instanz an das UndertowHttpBinding, das es lazy erstellt, wobei die UndertowHeaderFilterStrategy überschrieben wurde, die DefaultUndertowHttpBinding in seinem eigenen Konstruktor installiert. Sofern eine Bereitstellung kein benutzerdefiniertes Binding oder eine explizite headerFilterStrategy bereitstellte, wurde die Undertow-spezifische Filterung daher auf endpunktkonfigurierten Routen nie ausgeführt: Das Strategieobjekt wurde konstruiert und sofort ersetzt, bevor es überhaupt hätte konsultiert werden können. Die Folge ist, dass das Legacy-Präfix websocket. für Exchange-Header an der Undertow-Transportgrenze in keiner Richtung gefiltert wurde, sodass ein Undertow-HTTP-Consumer eingehende Wire-Header dieser Form auf den Exchange abbildete, wo ein Undertow-WebSocket-Producer sie als Dispatch-Anweisungen liest und dazu gebracht werden kann, an einen anderen Peer zuzustellen als den, den die Route ausgewählt hat; und Header-Namen, die Undertow selbst nicht akzeptiert, wurden auf den Exchange abgebildet, statt übersprungen zu werden. Rest-DSL-Consumer waren nie betroffen, da UndertowComponent UndertowRestHeaderFilterStrategy explizit zuweist, die die Undertow-Strategie erweitert. Dies ist keine Regression von CVE-2025-30177: Die Basisklasse HttpHeaderFilterStrategy konfiguriert den eingehenden Camel-Präfix-Filter selbst, sodass der durch dieses Advisory eingeführte Schutz weiterhin über die Basisklasse funktionierte und nie verloren ging. Die Änderung führte dazu, dass die Undertow-Strategie auf dem Endpunktpfad verwaist zurückblieb, mit der Folge, dass zwei spätere Korrekturen, die darin eingetragen wurden - eine, die von Undertow abgelehnte Header-Namen überspringt, eine, die das Legacy-Präfix websocket. in beide Richtungen filtert - auf eine Klasse angewendet wurden, die der Endpunkt nicht mehr verwendete, und in den Releases, die sie auslieferten, nie wirksam wurden. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, die das Problem behebt. Wer sich im 4.14.x-LTS-Release-Stream befindet, sollte auf 4.14.9 aktualisieren. Wer sich im 4.18.x-Release-Stream befindet, sollte auf 4.18.4 aktualisieren. Für Bereitstellungen, die nicht sofort aktualisieren können, sollte die Strategie explizit konfiguriert werden, statt sich auf die Standardeinstellung zu verlassen, beispielsweise indem eine UndertowHeaderFilterStrategy in der Registry gebunden und am Endpunkt als undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy referenziert wird, und zusätzlich sollten die Dispatch-Header an der Vertrauensgrenze mit removeHeaders(“websocket.*”) entfernt werden. Zu beachten ist eine verbleibende Einschränkung, die ein Upgrade nicht beseitigt: Die Undertow-Komponente behält die websocket.-Werte bewusst als Teil ihres extern sichtbaren API-Vertrags bei, und UndertowProducer liest sie mit in.getHeader, das überhaupt keine HeaderFilterStrategy konsultiert. Die wiederhergestellte Filterung ist daher ausschließlich an der Undertow-Transportgrenze eine Defense in Depth. Eine Route, die eine nicht vertrauenswürdige Nachricht von einem Nicht-Undertow-Consumer in einen Undertow-Producer transportiert, ist durch diesen Fix nicht geschützt und muss diese Header selbst entfernen.