CVE-2026-78329

Résumé

Vulnérabilité de validation incorrecte des entrées dans le composant Apache Camel Undertow. Ce problème affecte Apache Camel : de 4.11.0 jusqu'à avant 4.14.9, de 4.15.0 jusqu'à avant 4.18.4, et de 4.19.0 jusqu'à avant 4.22.0. UndertowEndpoint configurait par défaut son champ headerFilterStrategy avec la classe de base HttpHeaderFilterStrategy et plaçait cette instance dans le UndertowHttpBinding qu'il crée de manière paresseuse, écrasant ainsi la UndertowHeaderFilterStrategy que DefaultUndertowHttpBinding installe dans son propre constructeur. Sauf si un déploiement fournissait une liaison personnalisée ou une headerFilterStrategy explicite, le filtrage spécifique à Undertow n'était donc jamais exécuté sur les routes configurées sur l'endpoint : l'objet de stratégie était construit puis immédiatement remplacé avant de pouvoir être consulté. Par conséquent, l'ancien préfixe websocket. des en-têtes de l'Exchange n'était pas filtré à la frontière du transport undertow dans les deux sens, de sorte qu'un consommateur HTTP undertow mappait les en-têtes filaires entrants de cette forme sur l'Exchange, où un producteur WebSocket undertow les lit comme des directives de répartition et peut être amené à livrer à un pair autre que celui que la route a sélectionné ; et les noms d'en-têtes qu'undertow lui-même n'accepte pas étaient mappés sur l'Exchange au lieu d'être ignorés. Les consommateurs du DSL Rest n'ont jamais été affectés, car UndertowComponent assigne explicitement UndertowRestHeaderFilterStrategy, qui étend la stratégie undertow. Il ne s'agit pas d'une régression de CVE-2025-30177 : la classe de base HttpHeaderFilterStrategy configure elle-même le filtre du préfixe Camel entrant, si bien que la protection introduite par cet avis a continué de fonctionner à travers la classe de base et n'a jamais été perdue. Ce que ce changement a fait, c'est de laisser la stratégie undertow orpheline sur le chemin de l'endpoint, avec pour conséquence que deux corrections ultérieures qui y avaient été écrites - l'une ignorant les noms d'en-têtes qu'undertow rejette, l'autre filtrant l'ancien préfixe websocket. dans les deux sens - s'appliquaient à une classe que l'endpoint n'utilisait plus et ne prenaient jamais effet dans les versions qui les contenaient. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.22.0, qui corrige le problème. Les utilisateurs qui se trouvent sur la branche de versions LTS 4.14.x sont invités à passer à la version 4.14.9. Les utilisateurs qui se trouvent sur la branche de versions 4.18.x sont invités à passer à la version 4.18.4. Pour les déploiements qui ne peuvent pas être mis à niveau immédiatement, configurez la stratégie explicitement plutôt que de vous fier à la valeur par défaut, par exemple en enregistrant une UndertowHeaderFilterStrategy dans le registre et en la référençant sur l'endpoint comme undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, et supprimez en outre les en-têtes de répartition à la frontière de confiance avec removeHeaders(“websocket.*”). Notez une limitation résiduelle que la mise à niveau ne supprime pas : le composant undertow conserve délibérément les valeurs préfixées par websocket. dans le cadre de son contrat d'API visible de l'extérieur, et UndertowProducer les lit avec in.getHeader, qui ne consulte aucune HeaderFilterStrategy. Le filtrage rétabli ne constitue donc qu'une défense en profondeur à la frontière du transport undertow. Une route qui achemine un message non fiable d'un consommateur non-undertow vers un producteur undertow n'est pas protégée par ce correctif et doit supprimer elle-même ces en-têtes.