Une vulnérabilité d’Apache Tomcat permet aux utilisateurs de contourner certains contrôles d’accès en exploitant des requêtes HTTP/0.9 obsolètes.
Dans certaines configurations, cette faille pourrait permettre à des attaquants de contourner les contraintes de sécurité définies.
« Si une contrainte de sécurité était configurée pour autoriser les requêtes HEAD vers un URI, mais refuser les requêtes GET, l’utilisateur pouvait contourner cette contrainte lors de requêtes GET en envoyant une requête HEAD (non conforme aux spécifications) via HTTP/0.9 », a déclaré Apache dans son avis de sécurité.
Décryptage de la faille de contrôle d’accès de Tomcat
Répertoriée sous CVE-2026-24733, cette faille est considérée comme peu grave, mais touche plusieurs branches prises en charge d’Apache Tomcat ainsi que des versions plus anciennes en fin de vie (EOL).
La cause première réside dans la gestion par Tomcat de HTTP/0.9, une version obsolète du protocole antérieure aux mécanismes modernes de validation des méthodes HTTP et aux normes relatives aux en-têtes.
Avec le fonctionnement habituel de HTTP/1.1 ou HTTP/2, les administrateurs peuvent définir des contraintes de sécurité qui autorisent certaines méthodes — comme HEAD — tout en en refusant explicitement d’autres, comme GET, pour un URI donné.
Ces contraintes servent couramment à limiter l’accès au contenu des ressources tout en autorisant des vérifications limitées des métadonnées.
CVE-2026-24733 introduit une faille d’application dans un ensemble précis de conditions :
- Une contrainte de sécurité est configurée pour autoriser les requêtes HEAD.
- La même contrainte refuse les requêtes GET.
- Un attaquant envoie une requête HEAD malformée en utilisant les mécanismes de HTTP/0.9.
Comme Tomcat ne limitait pas le trafic HTTP/0.9 à un traitement réservé aux requêtes GET, sa logique d’analyse des méthodes pouvait traiter la requête d’une manière contournant la restriction GET prévue.
En pratique, du contenu qui aurait dû être bloqué pouvait devenir accessible dans ces circonstances étroitement définies.
Les versions suivantes sont concernées :
- Apache Tomcat 11.0.0-M1 à 11.0.14
- Apache Tomcat 10.1.0-M1 à 10.1.49
- Apache Tomcat 9.0.0.M1 à 9.0.112
- Les versions plus anciennes et non prises en charge sont également concernées et doivent être mises à niveau vers une branche prise en charge.
La vulnérabilité ne permet ni de contourner l’authentification, ni d’élever les privilèges, ni d’exécuter du code à distance.
Son exploitation dépend de la configuration et nécessite que le trafic HTTP/0.9 soit accepté de bout en bout par la pile de déploiement.
Dans de nombreuses architectures modernes, les reverse proxies, les répartiteurs de charge, les passerelles d’API ou les pare-feu applicatifs (WAF) normalisent ou rejettent les variantes de protocoles obsolètes avant qu’elles n’atteignent Tomcat.
Cependant, certaines chaînes de proxies atypiques, intégrations anciennes ou clients personnalisés peuvent ne pas fournir cette protection.
Au moment de la publication, Apache ne faisait état d’aucune preuve d’exploitation active dans la nature.
Réduire les risques liés au contrôle d’accès de Tomcat
Bien que CVE-2026-24733 soit considérée comme une vulnérabilité peu grave, elle constitue une raison concrète de revoir les processus de gestion des correctifs et les configurations de contrôle d’accès.
La gestion des protocoles obsolètes et les règles propres à chaque méthode peuvent créer des failles d’application subtiles si elles ne sont pas régulièrement testées et validées.
- Appliquez les correctifs à la dernière version prise en charge d’Apache Tomcat et validez la mise à jour par des tests afin de vous assurer que la vulnérabilité est entièrement corrigée.
- Examinez et validez les configurations des contraintes de sécurité, en particulier lorsque HEAD est autorisée et GET refusée, afin de confirmer que l’application des règles correspond à l’intention.
- Appliquez une validation stricte du protocole en périphérie en configurant les reverse proxies, les répartiteurs de charge ou les WAF pour rejeter ou normaliser le trafic HTTP/0.9.
- Mettez en place une liste blanche des méthodes HTTP afin de bloquer les méthodes de requête inutiles ou inattendues avant qu’elles n’atteignent Tomcat.
- Renforcez les configurations des connecteurs et du serveur Tomcat tout en limitant l’exposition directe à Internet grâce à une segmentation réseau appropriée.
- Activez la journalisation et la surveillance pour détecter les requêtes malformées, les rétrogradations de protocole ou l’utilisation anormale des méthodes HTTP, qui peuvent indiquer des tentatives de reconnaissance.
- Exploitez des outils degestion des vulnérabilités et testez régulièrement les plans de réponse aux incidents afin de garantir que les équipes peuvent détecter, analyser et contenir les scénarios de contournement des contrôles d’accès.
Ces mesures contribuent à limiter l’ampleur d’éventuels contournements des contrôles d’accès tout en renforçant la résilience à long terme de l’ensemble de la pile applicative.
Gérer les risques liés aux protocoles obsolètes
Bien que CVE-2026-24733 soit limitée dans sa portée et qu’aucune exploitation active n’ait été signalée, elle rappelle que la prise en charge des protocoles obsolètes et certains choix de configuration peuvent créer des failles subtiles dans les contrôles d’accès.
Les organisations qui exécutent Tomcat en production doivent se concentrer sur l’application des mises à jour, l’examen des configurations des contraintes et la cohérence du traitement des protocoles dans leurs environnements.
Même les failles peu graves peuvent créer une exposition inutile lorsqu’elles se combinent à des logiciels obsolètes ou à des paramètres non testés.
Ce type de risque lié au contrôle d’accès souligne la valeur plus large des solutions zero trust, conçues pour appliquer une vérification continue et réduire la confiance implicite dans les environnements applicatifs.