CVE-2026-46454
Apache Camel : Camel-Cometd : Les en-têtes des messages Bayeux entrants sont mappés dans l'Exchange sans HeaderFilterStrategy, permettant à des clients non authentifiés d'injecter des en-têtes de contrôle Camel
- Publié
- 6 juil. 2026
- Mise à jour
- 6 juil. 2026
- Attribution de CNA
- apache
- Preuve observée
- 6 août 2026
CVSS primaire
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HFaible · 30 prochains jours
- Percentile
- 55,5 %
- Date du modèle
- 21 sept. 2026
EPSS est une estimation statistique, et non une certitude ou une mesure d'impact. Combinez-le avec CVSS, le statut KEV, l'exposition et votre environnement.
Résumé
Vulnérabilité de validation d'entrée incorrecte dans le composant Cometd d'Apache Camel. Le composant camel-cometd mappe les en-têtes de messages Bayeux (CometD) entrants dans l'échange Camel sans appliquer de HeaderFilterStrategy. CometdBinding.populateExchangeFromMessage copie l'intégralité de la map ext.CamelHeaders fournie par le client CometD directement sur le message Camel (message.setHeaders), de sorte que tout nom d'en-tête — y compris les en-têtes de contrôle internes à Camel tels que CamelHttpUri, CamelFileName ou CamelJmsDestinationName — est accepté sans modification. Comme un CometdComponent n'installe aucune Bayeux SecurityPolicy par défaut, tout client capable d'effectuer la poignée de main Bayeux contre le point de terminaison CometD peut publier un tel message sans authentification. Un attaquant peut donc injecter des en-têtes de contrôle Camel arbitraires qui influencent le comportement des producteurs en aval dans la route (par exemple, rediriger un producteur HTTP, modifier un nom de fichier ou remplacer une destination JMS) ; les en-têtes injectés persistent également à travers les étapes internes direct, seda et vm. L'impact concret en aval dépend des producteurs utilisés par la route. Ce problème affecte Apache Camel : de 4.0.0 avant 4.14.8, de 4.15.0 avant 4.18.3, de 4.19.0 avant 4.21.0. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.21.0, qui corrige le problème. Si les utilisateurs sont sur le flux de versions LTS 4.14.x, il leur est suggéré de passer à la version 4.14.8. Si les utilisateurs sont sur le flux de versions 4.18.x, il leur est suggéré de passer à la version 4.18.3. Le correctif implémente un HeaderFilterStrategy dans la liaison camel-cometd (un TODO de longue date dans le code) qui filtre l'espace de noms des en-têtes Camel de manière insensible à la casse lors du mappage entrant, de sorte que les en-têtes Camel* / camel* fournis par le client ne sont plus copiés dans l'échange. Pour les déploiements qui ne peuvent pas être mis à niveau immédiatement, supprimez les en-têtes de contrôle Camel des messages CometD entrants avant qu'ils n'atteignent tout producteur en aval (par exemple, removeHeaders('Camel*') et removeHeaders('camel*') au début de la route), et installez une Bayeux SecurityPolicy explicite sur le CometdComponent afin que seuls les clients authentifiés puissent publier.
Sources
1Utilisation responsable
Utilisez les informations de vulnérabilité uniquement sur les systèmes que vous possédez ou que vous êtes autorisé à tester. Kitploit renvoie aux métadonnées de la recherche publique et ne stocke pas de code d'exploitation ni de charges utiles malveillantes.