CVE-2026-78329 in Camel
Zusammenfassung
von VulDB • 24.08.2026
Eine Schwachstelle aufgrund fehlerhafter 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 Feld `headerFilterStrategy` standardmäßig auf die Basis-`HttpHeaderFilterStrategy` gesetzt und diese Instanz in das lazy erstellte `UndertowHttpBinding` eingefügt, wodurch die `UndertowHeaderFilterStrategy`, die `DefaultUndertowHttpBinding` in seinem eigenen Konstruktor installiert, überschrieben wurde. Es sei denn, ein Deployment hat eine benutzerdefinierte Binding-Implementierung oder eine explizite `headerFilterStrategy` bereitgestellt, wurde die undertow-spezifische Filterung daher auf mit der Endpoint-Konfiguration versehenen Routen niemals ausgeführt: Das Strategieobjekt wurde konstruiert und sofort ersetzt, bevor es abgefragt werden konnte. Die Folge ist, dass das Legacy-WebSocket-Exchange-Header-Präfix `websocket.` an der Undertow-Transportgrenze in keiner Richtung gefiltert wurde; daher wurden eingehende Drahtheader dieser Form von einem Undertow-HTTP-Konsumeur auf den Exchange abgebildet, wo ein Undertow-WebSocket-Produzent sie als Dispatch-Direktiven liest und dazu gebracht werden kann, Nachrichten an einen anderen Peer zu liefern, als die Route ausgewählt hat; zudem wurden Header-Namen, die Undertow selbst nicht akzeptiert, auf den Exchange abgebildet, anstatt übersprungen zu werden. Rest DSL-Konsumeure waren nie betroffen, da `UndertowComponent` explizit `UndertowRestHeaderFilterStrategy` zuweist, das die Undertow-Strategie erweitert. Dies ist keine Regression von CVE-2025-30177: Die Basis-`HttpHeaderFilterStrategy` konfiguriert den inbound Camel-Prefix-Filter selbst, sodass der durch diesen Hinweis eingeführte Schutz weiterhin über die Basisklasse funktionierte und nie verloren ging. Was sich änderte, war, dass die Undertow-Strategie im Endpoint-Pfad verwaist wurde, mit der Folge, dass zwei nachfolgende Korrekturen, die in sie geschrieben wurden – eine zum Überspringen von Header-Namen, die Undertow ablehnt, und eine zur Filterung des Legacy-`websocket.`-Präfixes in beiden Richtungen – auf einer Klasse angewendet wurden, die der Endpoint nicht mehr verwendete, und daher in den Releases, die diese enthielten, nie wirksam wurden.
Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, welche das Problem behebt. Wenn Benutzer sich im LTS-Release-Zweig 4.14.x befinden, wird ihnen geraten, auf 4.14.9 zu aktualisieren. Wenn Benutzer sich im Release-Zweig 4.18.x befinden, wird ihnen geraten, auf 4.18.4 zu aktualisieren. Für Deployments, die nicht sofort upgraden können, sollte die Strategie explizit konfiguriert werden, anstatt sich auf den Standardwert zu verlassen; dies kann beispielsweise durch Bindung einer `UndertowHeaderFilterStrategy` im Registry und Referenzierung dieser am Endpoint als `undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy` erfolgen, sowie zusätzliches Entfernen der Dispatch-Header an der Vertrauensgrenze mittels `removeHeaders("websocket.*")`. Beachten Sie eine verbleibende Einschränkung, die ein Upgrade nicht beseitigt: Die Undertow-Komponente behält bewusst die `websocket.`-Werte als Teil ihres nach außen sichtbaren API-Vertrags bei, und der `UndertowProducer` liest diese mit `in.getHeader`, was überhaupt keine `HeaderFilterStrategy` abfragt. Das wiederhergestellte Filtern ist daher nur eine Defense-in-Depth-Maßnahme an der Undertow-Transportgrenze. Eine Route, die eine nicht vertrauenswürdige Nachricht von einem Nicht-Undertow-Konsumeur in einen Undertow-Produzenten transportiert, wird durch diese Korrektur nicht geschützt und muss diese Header selbst entfernen.
VulDB is the best source for vulnerability data and more expert information about this specific topic.