Qu'est-ce que les vulnérabilités d'Apache Tomcat : détection, correctifs et conseils

Principaux enseignements

• La plupart des risques liés à Tomcat proviennent de vulnérabilités CVE connues et non corrigées présentes dans des versions anciennes ou en fin de vie.
• Les failles à fort impact telles que CVE-2025-24813 et Ghostcat nécessitent des configurations spécifiques et risquées pour se déclencher.
• Pour détecter ces failles, il faut tout d'abord connaître toutes les versions de Tomcat que vous utilisez et savoir quels paramètres à risque sont activés.
• Effectuez des mises à niveau dès que possible, appliquez des mesures d'atténuation au niveau de la configuration lorsque cela n'est pas possible, et ne laissez jamais des versions en fin de vie exposées.

Une équipe active l’accès en écriture sur le servlet par défaut de Tomcat afin de prendre en charge une fonctionnalité de téléchargement de fichiers, la livre, puis passe à autre chose. Ce qu’elle néglige, c’est que la fonctionnalité « partial PUT » est activée par défaut ; l’une des conditions préalables à l’exploitation de la vulnérabilité CVE-2025-24813 est donc désormais réunie. Si cette application utilise également la persistance de session basée sur des fichiers de Tomcat à l’emplacement de stockage par défaut, et qu’elle intègre par hasard une bibliothèque pouvant être exploitée à des fins de désérialisation, il en résulte une exécution de code à distance sans authentification. La CISA l’a répertoriée dans son catalogue des vulnérabilités connues exploitées depuis le 1er avril 2025.

C'est le schéma récurrent qui se cache derrière les incidents liés à Tomcat. Il s'agit rarement d'une nouvelle attaque sophistiquée. Il s'agit généralement d'un problème connu qui a été laissé tel quel sur une ancienne version, ou d'un paramètre risqué que personne n'a pris la peine de revoir.

Ce guide passe en revue les risques, les CVE à connaître, ainsi que les méthodes permettant de détecter les vulnérabilités, d'appliquer les correctifs et de renforcer la sécurité de vos serveurs.

Quels sont les risques liés aux failles de sécurité d'Apache Tomcat ?

Tomcat est l'un des conteneurs de servlets Java les plus largement déployés, ce qui en fait une cible de choix. Lorsqu'une faille est découverte, les répercussions s'étendent rarement à un seul serveur.

Le scénario le plus grave est l'exécution de code à distance, dans laquelle un attaquant exécute des commandes arbitraires sur l'hôte. Vient ensuite la divulgation d'informations, où des fichiers tels que web.xml, du code source ou des secrets de configuration sont consultés sans authentification. Vient ensuite l'injection de contenu, où des données malveillantes s'introduisent dans des fichiers téléchargés ou dans les données de session. Et toute instance Tomcat compromise constitue un point d'ancrage idéal pour effectuer un déplacement latéral vers le reste du réseau.

Retour à la réalité : l’argument « Nous avons effectué la mise à niveau, donc tout va bien » ne tient plus si certaines instances utilisent une branche en fin de vie. Tomcat 8.5 a atteint sa fin de vie en amont le 31 mars 2024 et n’a jamais bénéficié d’un correctif en amont pour la vulnérabilité CVE-2025-24813. En l’absence d’un éditeur fournissant des correctifs après la fin de vie, ces serveurs restent exposés, quel que soit le nombre d’autres machines que vous avez mises à jour.

Vulnérabilités courantes d'Apache Tomcat

Les vulnérabilités CVE de Tomcat s'articulent autour d'une poignée de thèmes. La gestion non sécurisée des requêtes, la confiance accordée aux protocoles, la résolution des chemins d'accès, la logique d'authentification et les paramètres par défaut non sécurisés en matière de cryptographie en constituent la majeure partie. Voici celles qu'il convient de connaître, avec les versions concernées et corrigées publiées par Apache.

CVE-2025-24813 (Exécution de code partielle via PUT)

Ce cas associe un bug d'équivalence de chemin à une désérialisation non sécurisée, et les conditions préalables sont spécifiques mais tout à fait réalistes. Les opérations d'écriture doivent être activées sur le servlet par défaut, ce qui n'est pas le cas par défaut. La fonctionnalité « PUT partiel » doit être activée, ce qui est le cas par défaut.

L'application doit utiliser la persistance de session basée sur des fichiers de Tomcat à l'emplacement de stockage par défaut. Elle doit également inclure une bibliothèque susceptible d'être exploitée dans le cadre d'une attaque par désérialisation. Si ces quatre conditions sont réunies, un attaquant peut préparer une charge utile sérialisée à l'aide d'une requête PUT partielle, puis déclencher son exécution via une requête suivante contenant le JSESSIONID correspondant.

Elle a été rendue publique le 10 mars 2025, et la CISA l'a ajoutée au catalogue des vulnérabilités connues exploitées le 1er avril 2025.

CVE-2020-1938 (Ghostcat)

Ghostcat est une faille de lecture et d’inclusion de fichiers dans le connecteur AJP, qui était historiquement livré activé sur le port 8009 et lié à toutes les adresses configurées. Un attaquant distant non authentifié capable d’accéder à ce port pouvait récupérer des fichiers arbitraires depuis n’importe quel emplacement de l’application web, y compris dans les répertoires WEB-INF et META-INF, et forcer Tomcat à traiter n’importe quel fichier de l’application comme un fichier JSP. La vulnérabilité peut conduire à l’exécution de code lorsque l’application stocke également des fichiers téléchargés au sein de l’application web. Les correctifs ont été intégrés dans les versions 7.0.100, 8.5.51 et 9.0.31 ; c’est également à partir de ces versions qu’Apache a commenté le connecteur dans le fichier server.xml par défaut, déplacé son adresse de liaison par défaut vers le loopback et rendu obligatoire l’utilisation d’une clé secrète AJP. Cette vulnérabilité figure dans le catalogue KEV depuis le 3 mars 2022.

CVE-2025-55752 (traversée de répertoires)

Une faille de réécriture dans la « Rewrite Valve » normalisait les URL réécrites avant de les décoder. Lorsque les règles de réécriture intègrent des paramètres de requête dans l'URL, un attaquant pouvait manipuler l'URI de la requête pour contourner les protections sur /WEB-INF/ et /META-INF/, ce qui pouvait permettre l'exécution de code si la méthode PUT était également activée. Apache précise que cette combinaison est peu probable, car la méthode PUT est généralement réservée aux utilisateurs de confiance, mais ce cas mérite tout de même d'être étudié. Cela montre comment un correctif apporté dans une version peut réintroduire discrètement un risque dans une autre.

CVE-2026-29146 (Attaque de type « Padding Oracle » sur EncryptInterceptor)

Cela nous rappelle qu'un paramètre par défaut peut constituer une faille de sécurité. L’EncryptInterceptor, utilisé pour chiffrer le trafic du cluster, était configuré par défaut en mode CBC, qui est vulnérable aux attaques de type « padding oracle ». Tout déploiement exécutant cet intercepteur dans son mode de chiffrement par défaut était potentiellement exposé, sans qu’un administrateur n’ait sélectionné de paramètre inhabituel. Pour les versions couvertes par le programme « Endless Lifecycle Support » de TuxCare, les correctifs rétroportés sont répertoriés par version dans le suivi CVE, qui indique précisément quelles versions couvertes disposent du correctif.

CVE-2026-34486 (Contournement d'EncryptInterceptor)

Le correctif pour la vulnérabilité CVE-2026-29146 a été intégré aux versions 9.0.116, 10.1.53 et 11.0.20, mais il comportait une erreur qui permettait de contourner complètement l'EncryptInterceptor. Notez bien la version de Tomcat 11 mentionnée ici. Le correctif avait été écrit pour la version 11.0.19, mais le vote de validation de cette version a échoué ; c'est donc la version 11.0.20 qui a été la première à pouvoir être téléchargée. Ce sont précisément ces trois versions qui sont concernées, et les versions 9.0.117, 10.1.54 et 11.0.21 corrigent cette vulnérabilité. La CISA a ajouté cette vulnérabilité au catalogue KEV le 4 août 2026 ; par conséquent, une mise à niveau de cluster qui s’est arrêtée au premier correctif n’est pas terminée.

CVE-2026-55957 (Contournement de l'authentification GSSAPI)

Lorsque JNDIRealm était configuré pour authentifier les connexions à l'aide de GSSAPI, un attaquant pouvait s'authentifier sans disposer du mot de passe correct. Ni attaque par force brute, ni identifiants volés. La logique d’authentification ne parvenait tout simplement pas à appliquer la vérification. Ce qui est étrange, c’est la chronologie des événements. Le correctif a été discrètement intégré dans les versions 9.0.102, 10.1.39 et 11.0.5, et le problème n’a été rendu public que le 29 juin 2026, soit plus d’un an plus tard. Toutes les versions antérieures ou égales à 9.0.100, 10.1.36 ou 11.0.4 doivent faire l’objet d’une attention particulière. Les versions plus récentes étaient déjà protégées avant même que le CVE ne se voie attribuer un numéro.

CVE-2026-43512 (Mot de passe « null » dans l'authentification Digest)

Le mode de défaillance est ici presque trop simple pour être vrai. L’authentificateur Digest de Tomcat acceptait la chaîne de caractères « null » comme mot de passe valide pour tout nom d’utilisateur n’existant pas dans le Realm configuré. Ainsi, un utilisateur n’appartenant pas au système pouvait s’authentifier en devinant cette chaîne. L’ampleur de l’impact dépend de ce qui se trouve derrière l’authentification Digest, mais la condition préalable est très facile à remplir. Cette faille a été rendue publique le 12 mai 2026 et corrigée dans les versions 9.0.118, 10.1.55 et 11.0.22.

Le saviez-vous ? En mars 2025, Palo Alto Networks a bloqué 125 856 scans, sondages et tentatives d'exploitation liés à la vulnérabilité CVE-2025-24813 et à deux failles connexes d'Apache Camel, provenant de plus de 70 pays, dans les trois semaines qui ont suivi leur divulgation.

Comment détecter et évaluer les vulnérabilités d'Apache Tomcat

La détection est avant tout un problème d'inventaire. On ne peut pas corriger ce qu'on n'a pas trouvé, et les grands parcs informatiques ont tendance à accumuler des instances Tomcat qui ne figurent sur aucune liste. Suivez ces trois étapes dans l'ordre.

Répertorier toutes les instances et toutes les versions

Identifiez tous les déploiements de Tomcat, y compris les applications qui l'intègrent, telles que les applications Spring Boot exécutant le serveur Tomcat intégré. Notez la version exacte, et non le nom du dossier. Les installations sont copiées et renommées ; le chemin d'accès n'est donc pas fiable.

Conseil de pro : utilisez le script de vérification de la version fourni avec le logiciel plutôt que d'essayer de deviner à partir du chemin d'installation. La commande $CATALINA_HOME/bin/version.sh affiche les versions exactes de Tomcat et de la JVM, c'est-à-dire les informations dont vous avez besoin pour toute évaluation sérieuse.

Mettre en correspondance les versions avec les CVE connues

Comparez chaque version avec la base de données NVD, les avis de sécurité Tomcat correspondant à votre branche et le catalogue KEV de la CISA. Tout élément figurant dans le catalogue KEV doit être considéré comme faisant l'objet d'une exploitation active et être placé en tête de la file d'attente.

Vérifiez les indicateurs de configuration à risque

Plusieurs vulnérabilités CVE de Tomcat ne peuvent être exploitées que lorsque certains paramètres spécifiques sont activés. Vérifiez si le paramètre « readonly » du servlet par défaut est défini sur « false », si l’option « allowPartialPut » est activée, si le connecteur AJP est accessible, et si JNDIRealm, l’authentification Digest ou l’EncryptInterceptor sont effectivement utilisés. C’est cette configuration qui fait la différence entre une vulnérabilité CVE simplement présente et une vulnérabilité réellement exploitable.

Comment corriger et combler les failles de sécurité d'Apache Tomcat

L'application de correctifs à Tomcat est généralement simple lorsqu'une version corrigée est disponible. La difficulté réside dans les serveurs pour lesquels la mise à niveau est bloquée ou dont la version a déjà atteint sa fin de vie.

Passer à une version corrigée

Pour les branches activement maintenues, passez à une version fixe et considérez les numéros par CVE indiqués dans le tableau ci-dessus comme un seuil minimal plutôt que comme un objectif à atteindre. Optez pour la dernière version disponible dans votre branche, c'est-à-dire actuellement la 9.0.121, la 10.1.59 ou la 11.0.25. Si vous vous arrêtez à la correction minimale pour un seul CVE, vous continuerez à cumuler toutes les vulnérabilités publiées depuis. Le CVE-2026-29146 en est un exemple édifiant. Ses correctifs initiaux ont été intégrés dans les versions 9.0.116, 10.1.53 et 11.0.20, et ces trois versions se sont avérées vulnérables au contournement de correctif CVE-2026-34486 ; le seuil minimal réel est donc 9.0.117, 10.1.54 ou 11.0.21.

L'outil « CVE Tracker » de TuxCare dédié à Apache Tomcat est très pratique pour vérifier quelles vulnérabilités CVE affectent une version spécifique, qu'elle soit ancienne ou en fin de vie.

Appliquez les mesures d'atténuation de configuration lorsque vous ne pouvez pas encore effectuer la mise à niveau

Si la mise à jour de la version doit être reportée, bloquez la voie d’exploitation au niveau de la couche de configuration. Laissez la valeur « readonly » définie sur « true » pour le servlet par défaut ; c’est la valeur par défaut, qui supprime d’elle-même la condition préalable relative au servlet « writable ». Si des écritures sont réellement nécessaires, définissez « allowPartialPut » sur « false » partout où l’application n’a pas besoin de téléchargements partiels. Ce paramètre existe depuis des années, y compris dans la version 8.5.100 et les anciennes versions 9.0 ; il s’agit donc d’une option viable sur les serveurs non mis à jour. Désactivez ensuite le connecteur AJP si vous ne l’utilisez pas, ou liez-le à l’interface dont votre proxy a réellement besoin et attribuez-lui un secret si vous l’utilisez.

Attention : la fonction PUT partielle est activée par défaut, mais la persistance de session basée sur des fichiers ne l’est pas, pas plus qu’un servlet par défaut accessible en écriture. Dès qu’un utilisateur active l’écriture sur le servlet par défaut pour une fonctionnalité de téléchargement de fichiers, l’une des conditions préalables non par défaut est remplie. Ajoutez à cela la persistance de session basée sur des fichiers à l’emplacement de stockage par défaut et une bibliothèque pouvant être détournée à des fins de désérialisation, et la chaîne complète de la vulnérabilité CVE-2025-24813 est activée. Considérez l’option « activer les écritures » comme une décision de sécurité plutôt que comme un simple réglage de commodité, et profitez-en pour vérifier la présence des deux autres conditions.

Choisissez entre une mise à jour manuelle ou automatisée et prenez en charge les versions en fin de vie (EOL)

La manière dont vous appliquez les correctifs dépend de la taille de la flotte, des exigences en matière de contrôle des modifications auxquelles vous devez vous conformer, et du fait que la version bénéficie-t-elle encore de correctifs en amont.

Tomcat est un conteneur de servlets relativement autonome, et la plupart des avis de sécurité concernent ses propres composants, tels que Catalina, Coyote et Jasper. Les déploiements en production doivent toutefois continuer à surveiller le JDK et toutes les bibliothèques intégrées à l’application, car ces dépendances comportent leurs propres vulnérabilités. Dans un cas comme celui de CVE-2025-24813, c’est également une bibliothèque intégrée qui fournit la chaîne de gadgets permettant de transformer une désérialisation non sécurisée en exécution de code.

Lorsque les correctifs en amont ne sont plus pris en compte dans la version que vous utilisez actuellement, c’est là qu’intervient le service « Endless Lifecycle Support » de TuxCare pour Apache Tomcat. Il intègre les correctifs CVE dans des versions « figées » de Tomcat, fournies à partir d’un référentiel TuxCare, ce qui vous permet de conserver votre version actuelle au lieu de passer à une nouvelle version que vous n’avez pas testée. La couverture s'étend actuellement à certaines versions de Tomcat 7, 8.5, 9.0 et 10.1, à savoir 7.0.109, 8.5.100, 9.0.46, 9.0.50, 9.0.75, 9.0.83, 9.0.87, 9.0.90, 9.0.100, 10.1.18 et 10.1.42 ; la documentation présente la matrice actuelle. Cette plage est importante car le problème ne se limite pas à la fin de vie de la branche. Tomcat 7 et 8.5 ont tous deux dépassé cette date depuis longtemps, la version 8.5 depuis le 31 mars 2024, et la fin du support de Tomcat 9.0 a désormais été annoncée pour le 31 mars 2027. Mais une application bloquée sur une ancienne version 9.0 ou 10.1 ne bénéficie pas des correctifs qu’Apache ajoute dans les versions ultérieures de cette même branche.

En résumé, si votre version de Tomcat bénéficie toujours de correctifs en amont, effectuez des mises à jour à une fréquence régulière. Si elle est en fin de vie ou si la version de référence en amont a évolué, optez pour les correctifs fournis par le fournisseur ou planifiez la migration. Continuer à l'utiliser sans correctifs n'est pas une option envisageable.

Bonnes pratiques pour sécuriser Apache Tomcat

Le renforcement de la sécurité de Tomcat ne repose pas tant sur des mesures de contrôle sophistiquées que sur le fait de conserver les paramètres par défaut sécurisés, de désactiver ce que vous n'utilisez pas et de renforcer la sécurité de tout ce que vous exposez. Quelques habitudes cohérentes suffisent à combler la plupart des failles courantes.

Continuez à utiliser les versions prises en charge

Veillez à ce que Tomcat et le JDK restent à des versions qui bénéficient encore de correctifs de sécurité. Pour les versions que le développeur en amont a cessé de prendre en charge, le support à vie d'Endless pour Apache Tomcat garantit la poursuite de la fourniture de correctifs sans migration forcée.

Verrouillage des connecteurs et du servlet par défaut

Appliquez le principe du « privilège minimal » à la surface d'exposition de Tomcat. Laissez le servlet par défaut en lecture seule, sauf si vous avez une raison impérieuse de ne pas le faire ; désactivez la méthode PUT partielle si vous ne l'utilisez pas ; et ne laissez jamais l'AJP accessible depuis des réseaux non fiables.

Conseil d'initié : si vous utilisez AJP, associez le connecteur à l'interface dont votre proxy de confiance a réellement besoin, limitez l'accès à celle-ci au niveau de la couche réseau et définissez un secret. Ghostcat était d'autant plus dangereux que ce port restait ouvert par défaut lors des installations standard pendant bien plus d'une décennie.

Placez Tomcat derrière un proxy inverse et surveillez-le

Pour la plupart des déploiements en production, placez un proxy inverse sécurisé devant Tomcat plutôt que d’exposer directement le connecteur de l’application. Supprimez les applications d’exemple et limitez strictement l’accès à l’application de gestion si vous la conservez. Surveillez les journaux d’accès pour détecter toute requête inhabituelle, en particulier celles qui tentent d’accéder à /WEB-INF/ ou qui envoient des requêtes PUT inattendues.

Protégez votre Apache Tomcat avec TuxCare

Les vulnérabilités d'Apache Tomcat se manifestent rarement. Elles restent discrètement présentes dans les configurations par défaut et les versions en fin de vie jusqu'à ce que quelqu'un analyse votre serveur. La solution est fastidieuse mais fiable : identifiez les composants que vous utilisez, appliquez les correctifs disponibles, mettez en place des mesures d'atténuation pour ceux qui n'en disposent pas, et ne laissez jamais une version en fin de vie exposée. Si vous êtes bloqué sur une version que le fournisseur en amont ne prend plus en charge, découvrez comment TuxCare propose un support à cycle de vie illimité pour Apache Tomcat.

Résumé

Nom de l'article

Qu'est-ce que les vulnérabilités d'Apache Tomcat : détection, correctifs et conseils

Description

Assurez la sécurité de vos serveurs Apache Tomcat ! Apprenez à identifier les failles de sécurité, à les corriger et à respecter les bonnes pratiques pour garantir une sécurité optimale.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur