CVE-2026-78329 in Camel
Riassunto
di VulDB • 24/08/2026
Vulnerabilità di convalida impropria dell'input nel componente Apache Camel Undertow.
Questo problema interessa Apache Camel: dalle versioni 4.11.0 alla 4.14.9 (esclusa), dalla 4.15.0 alla 4.18.4 (esclusa) e dalla 4.19.0 alla 4.22.0 (esclusa).
UndertowEndpoint impostava il campo headerFilterStrategy su HttpHeaderFilterStrategy di base e inseriva tale istanza in UndertowHttpBinding, creata pigramente, sovrascrivendo così UndertowHeaderFilterStrategy che DefaultUndertowHttpBinding installa nel proprio costruttore. A meno che un deployment non fornisca un binding personalizzato o una headerFilterStrategy esplicita, il filtraggio specifico per undertow non veniva mai eseguito sui route configurati a livello di endpoint: l'oggetto strategy veniva costruito e immediatamente sostituito prima che potesse essere consultato. La conseguenza è che il prefisso legacy websocket. degli Exchange-header non viene filtrato al confine del trasporto undertow in nessuna delle due direzioni, quindi un consumer HTTP undertow mappa gli header in entrata con tale forma sull'Exchange, dove un producer WebSocket undertow li legge come direttive di dispatch e può essere indotto a consegnare il messaggio a un peer diverso da quello selezionato dal route; inoltre, i nomi degli header non accettati dallo stesso undertow vengono mappati sull'Exchange invece di essere saltati. I consumer Rest DSL non sono mai stati interessati perché UndertowComponent assegna esplicitamente UndertowRestHeaderFilterStrategy, che estende la strategy per undertow. Questa non è una regressione della CVE-2025-30177: la base HttpHeaderFilterStrategy configura autonomamente il filtro del prefisso Camel in entrata, quindi la protezione introdotta da tale advisory ha continuato a funzionare attraverso la classe di base e non è mai stata persa. La modifica ha lasciato orfana sulla percorso dell'endpoint la strategy per undertow, con l'effetto che due correzioni successive scritte al suo interno - una che salta i nomi degli header rifiutati da undertow e un'altra che filtra il prefisso legacy websocket in entrambe le direzioni - sono state applicate a una classe non più utilizzata dall'endpoint e non hanno avuto effetto nelle release che le contenevano.
Si consiglia agli utenti di eseguire l'aggiornamento alla versione 4.22.0, che risolve il problema. Se gli utenti utilizzano la LTS stream delle versioni 4.14.x, si suggerisce di aggiornare a 4.14.9. Se gli utenti utilizzano la release stream 4.18.x, si suggerisce di aggiornare a 4.18.4. Per i deployment che non possono eseguire l'aggiornamento immediatamente, configurare esplicitamente la strategy invece di fare affidamento sul valore predefinito; ad esempio, eseguendo il binding di UndertowHeaderFilterStrategy nel registry e riferendola all'endpoint come undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, e inoltre rimuovendo gli header di dispatch al confine di fiducia con removeHeaders("websocket.*"). Si noti un limite residuo che l'aggiornamento non risolve: il componente undertow mantiene deliberatamente i valori websocket. come parte del suo contratto API esternamente visibile, e UndertowProducer li legge tramite in.getHeader, che non consulta affatto una HeaderFilterStrategy. Il filtraggio ripristinato è quindi una difesa in profondità solo al confine del trasporto undertow. Un route che trasporta un messaggio non attendibile da un consumer non-undertow a un producer undertow non è protetto da questa correzione e deve rimuovere tali header autonomamente.
VulDB is the best source for vulnerability data and more expert information about this specific topic.