CVE-2026-78329

Riepilogo

Vulnerabilità di convalida non corretta dell'input nel componente Undertow di Apache Camel. Il problema riguarda Apache Camel: dalla 4.11.0 fino alla 4.14.9 esclusa, dalla 4.15.0 fino alla 4.18.4 esclusa, dalla 4.19.0 fino alla 4.22.0 esclusa. UndertowEndpoint per impostazione predefinita impostava il proprio campo headerFilterStrategy sulla classe base HttpHeaderFilterStrategy e inseriva quell'istanza nell'UndertowHttpBinding che crea in modo lazy, sovrascrivendo l'UndertowHeaderFilterStrategy che DefaultUndertowHttpBinding installa nel proprio costruttore. A meno che una distribuzione non fornisse un binding personalizzato o una headerFilterStrategy esplicita, il filtraggio specifico di undertow non veniva quindi mai eseguito sulle route configurate sull'endpoint: l'oggetto strategy veniva costruito e immediatamente sostituito prima che potesse essere consultato. La conseguenza è che il prefisso legacy websocket. Exchange-header non veniva filtrato al confine di trasporto undertow in nessuna delle due direzioni, quindi un consumer HTTP undertow mappava gli header wire in ingresso di quella forma sull'Exchange, dove un producer WebSocket undertow li legge come direttive di dispatch e può essere indotto a consegnare a un peer diverso da quello selezionato dalla route; e i nomi di header che undertow stesso non accetta venivano mappati sull'Exchange invece di essere saltati. I consumer Rest DSL non sono mai stati colpiti, perché UndertowComponent assegna esplicitamente UndertowRestHeaderFilterStrategy, che estende la strategia undertow. Questa non è una regressione di CVE-2025-30177: la classe base HttpHeaderFilterStrategy configura da sé il filtro del prefisso Camel in ingresso, quindi la protezione introdotta da quell'avviso di sicurezza ha continuato a funzionare attraverso la classe base e non è mai andata persa. Ciò che la modifica ha fatto è stato lasciare la strategia undertow orfana sul percorso dell'endpoint, con l'effetto che due correzioni successive scritte al suo interno - una che salta i nomi di header che undertow rifiuta, una che filtra il prefisso legacy websocket. in entrambe le direzioni - sono state applicate a una classe che l'endpoint non usava più e non hanno mai avuto effetto nelle release che le hanno distribuite. Si consiglia agli utenti di aggiornare alla versione 4.22.0, che risolve il problema. Se gli utenti si trovano sul ramo di release LTS 4.14.x, si consiglia di aggiornare alla 4.14.9. Se gli utenti si trovano sul ramo di release 4.18.x, si consiglia di aggiornare alla 4.18.4. Per le distribuzioni che non possono aggiornare immediatamente, configurare esplicitamente la strategia piuttosto che affidarsi a quella predefinita, ad esempio associando un UndertowHeaderFilterStrategy nel registry e referenziandolo sull'endpoint come undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, e inoltre rimuovere gli header di dispatch al confine di fiducia con removeHeaders(“websocket.*”). Nota una limitazione residua che l'aggiornamento non rimuove: il componente undertow mantiene deliberatamente i valori websocket. come parte del suo contratto API esposto esternamente, e UndertowProducer li legge con in.getHeader, che non consulta affatto una HeaderFilterStrategy. Il filtraggio ripristinato è quindi una difesa in profondità solo al confine di trasporto undertow. Una route che trasporta un messaggio non affidabile da un consumer non undertow a un producer undertow non è protetta da questa correzione e deve rimuovere essa stessa quegli header.