Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements :
- La vulnérabilité CVE-2025-24813 peut permettre à des attaquants non authentifiés d'exécuter du code à distance, de divulguer des informations ou d'injecter du contenu sur des serveurs Tomcat, mais uniquement lorsque le servlet par défaut est configuré pour autoriser l'écriture (désactivée par défaut) et que certaines autres conditions non standard sont remplies.
- Les équipes concernées doivent recenser leurs déploiements Tomcat, vérifier si des restrictions de sécurité sont en place et effectuer la mise à jour vers des versions corrigées dès que possible.
- Les environnements Tomcat plus anciens ou difficiles à mettre à niveau nécessitent un plan clair de réduction des risques, plutôt que de s'appuyer sur des versions non corrigées et en fin de vie.
Si vous gérez des instances Apache Tomcat en production, la vulnérabilité CVE-2025-24813 est l'une de celles qui requièrent votre attention immédiate. Non pas parce qu'elle fait sensation ou fait la une des journaux, mais parce qu'elle représente un risque réel et exploitable dans des configurations étonnamment courantes.
Il ne s'agit pas d'un cas théorique isolé qui ne concernerait que les utilisateurs exécutant Tomcat sur un Raspberry Pi en mode débogage. Nous parlons ici d'une vulnérabilité susceptible d'affecter de véritables environnements de production, offrant potentiellement aux pirates un point d'ancrage dans l'infrastructure de votre application. Voyons ensemble en quoi consiste exactement la vulnérabilité CVE-2025-24813, qui doit s'en préoccuper et comment y remédier sans que cela ne transforme votre semaine en crise.
Qu'est-ce que CVE-2025-24813 ?
La vulnérabilité CVE-2025-24813 est une faille d'équivalence de chemin d'accès dans Apache Tomcat pouvant entraîner l'exécution de code à distance sans authentification, la divulgation d'informations ou l'injection de contenu dans des fichiers téléchargés. Concrètement, un attaquant capable d'accéder à une instance Tomcat vulnérable pourrait télécharger un fichier malveillant et amener Tomcat à l'exécuter, sans avoir besoin d'identifiants.
Cette vulnérabilité provient de la manière dont la gestion des requêtes PUT partielles de Tomcat construit les chemins d'accès aux fichiers temporaires. L'implémentation d'origine générait un nom de fichier temporaire à partir du nom et du chemin d'accès fournis par l'utilisateur, en remplaçant le séparateur de chemin par un point. Associée à la persistance de session basée sur des fichiers de Tomcat, cette conception permet à un attaquant de télécharger une charge utile Java sérialisée spécialement conçue dans le répertoire de session, puis de déclencher la désérialisation à l'aide d'une requête GET suivante contenant un identifiant de session correspondant cookie . Il en résulte l'exécution de code à distance.
Ce qui rend cette faille particulièrement préoccupante, c'est qu'aucune authentification n'est requise et que la charge utile peut être encodée en Base64 pour échapper aux règles de détection courantes. Une fois qu'un pirate a compris le principe de la collision de chemins d'accès et le déclencheur de désérialisation, l'exploitation ne demande plus qu'un simple clic.
Cela dit, cette vulnérabilité est soumise à certaines conditions préalables. Pour qu'elle puisse être exploitée, toutes les conditions suivantes doivent être réunies : les écritures doivent être activées sur le servlet par défaut (désactivées par défaut – le paramètre dans conf/web.xml doit être défini sur false), Tomcat est configuré pour utiliser la persistance de session basée sur des fichiers (et non la configuration par défaut), et le classpath de l'application inclut une chaîne de gadgets de désérialisation que l'attaquant peut exploiter. C'est précisément pour cette raison qu'Apache a initialement classé le CVE comme « Important » plutôt que « Critique ». Mais lorsque toutes ces conditions sont réunies, l'impact est la compromission totale du serveur – et la CISA l'a ajouté au catalogue des vulnérabilités connues exploitées quelques semaines après sa divulgation. –
Quelles versions de Tomcat sont concernées ?
La faille CVE-2025-24813 touche plusieurs branches d'Apache Tomcat, bien que les versions vulnérables exactes dépendent de la version majeure que vous utilisez. Voici le détail :
- Apache Tomcat 11.0.x présente une vulnérabilité dans les versions 11.0.0-M1 à 11.0.2. Le correctif a été intégré dans la version 11.0.3; vous devez donc disposer de la version 11.0.3 ou d'une version ultérieure pour bénéficier du correctif.
- Apache Tomcat 10.1.x est vulnérable dans les versions 10.1.0-M1 à 10.1.34. Le correctif est inclus dans la version 10.1.35 et les versions ultérieures.
- Apache Tomcat 9.0.x est vulnérable dans les versions 9.0.0.M1 à 9.0.98. Vous devez disposer de la version 9.0.99 ou une version ultérieure pour corriger cette vulnérabilité.
- Apache Tomcat 8.5.x a atteint sa fin de vie le 31 mars 2024, avant que cette vulnérabilité CVE ne soit divulguée. Le projet Apache Tomcat n'a pas publié de correctif communautaire pour la version 8.5 ; par conséquent, tout déploiement de la version 8.5.x reste exposé de manière permanente, à moins que vous ne migriez vers une branche prise en charge ou que vous ne bénéficiez d'une couverture via un fournisseur de support étendu commercial.
Il convient de noter que Tomcat 8.5 et toutes les versions antérieures – les branches 8.0.x et 7.0.x – ont toutes atteint leur fin de vie et ne bénéficieront pas d'un correctif communautaire pour la vulnérabilité CVE-2025-24813. Si vous utilisez l'une de ces branches, vos seules options consistent à migrer vers une version prise en charge ou à bénéficier d'une couverture via un fournisseur de support étendu commercial. Nous aborderons ces deux options dans un instant.
Il est essentiel de comprendre que ce problème ne touche pas uniquement les versions de pointe ou les configurations peu courantes. Cette vulnérabilité concerne les principales versions de Tomcat actuellement déployées en production, y compris les versions 9.0 et 8.5, largement répandues, qui sont à la base d'innombrables applications d'entreprise.
Comprendre le scénario d'exploitation
Pour bien saisir le risque, il faut comprendre à quel moment et de quelle manière cette vulnérabilité a réellement une incidence dans les environnements de production.
Le scénario d'exploitation de la vulnérabilité CVE-2025-24813 s'articule autour du servlet par défaut de Tomcat – le composant qui gère les requêtes directes sur les fichiers – et d'une fonctionnalité appelée « partial PUT », qui permet aux clients de télécharger des parties d'un fichier en plusieurs requêtes. Par défaut, le servlet par défaut est en lecture seule et ignore complètement les requêtes PUT, ce qui explique pourquoi la plupart des installations ne sont pas exposées. La vulnérabilité n'est exploitable que lorsqu'un administrateur a explicitement défini le readonly sur false dans conf/web.xml, ce qui active les téléchargements via le servlet par défaut.
C'est là que ça devient intéressant : même lorsque l'écriture est activée, l'exploitation nécessite des éléments supplémentaires. Tomcat doit être configuré pour la persistance des sessions sur fichier (le gestionnaire FileStore plutôt que des sessions en mémoire), le classpath de l'application doit inclure une chaîne de gadgets de désérialisation, et l'attaquant doit pouvoir accéder au point de terminaison de téléchargement via le réseau.
Lorsque ces conditions sont réunies, la chaîne d'attaque est courte. L'attaquant envoie une requête PUT partielle qui télécharge une charge utile Java sérialisée vers un chemin qu'il contrôle. Comme l'implémentation de la requête PUT partielle de Tomcat convertit l'URI de la requête en un nom de fichier temporaire – en remplaçant les séparateurs de chemin par des points –, le fichier téléchargé se retrouve exactement à l'endroit où Tomcat cherchera plus tard les données de session. Une requête GET suivante contenant un cookie spécialement conçu, Tomcat désérialise le fichier, exécute la chaîne de gadgets et permet à l'attaquant d'exécuter du code à distance. Aucune authentification n'est requise à aucune étape.
Concrètement, cela ne signifie pas qu’« un pirate peut voir un point de terminaison supplémentaire », mais plutôt qu’« un pirate télécharge une charge utile, envoie une requête de plus et exécute du code sous l’identité du processus Tomcat ».
Si votre application n'autorise pas les opérations d'écriture sur le servlet par défaut ou n'utilise pas la persistance de session sur fichier, vous n'êtes pas exposé au risque d'exécution de code à distance lié à cette vulnérabilité (CVE). Vous pourriez toutefois être exposé aux variantes de divulgation d'informations ou d'injection de contenu dans des conditions légèrement différentes ; il est donc toujours recommandé d'appliquer le correctif, mais l'urgence dépend entièrement de votre configuration.
Évaluer votre exposition
Avant de commencer à appliquer les correctifs, il est utile de prendre un moment pour vérifier si vos déploiements Tomcat spécifiques sont réellement exposés à la vulnérabilité CVE-2025-24813.
- Commencez par vérifier les versions de Tomcat. Cela peut sembler évident, mais dans les environnements complexes comportant plusieurs instances de Tomcat, vous seriez surpris de voir à quel point il est fréquent que les équipes ne disposent pas d'un inventaire complet. Si vous utilisez une version antérieure à celles corrigées mentionnées plus haut, vous êtes potentiellement vulnérable. N'oubliez pas les instances de Tomcat qui s'exécutent dans des conteneurs Docker, cachées dans des déploiements de microservices ou intégrées à d'autres applications.
- Second, review your security constraint configurations. Look at the ‘web.xml’ files (and any programmatic security configurations) for your deployed applications. Are you using ‘<security-constraint>’ elements to protect resources? Are you relying on Tomcat’s built-in authentication mechanisms? If the answer is yes, you need to treat this vulnerability seriously.
- Troisièmement, examinez votre architecture de déploiement. Vos instances Tomcat sont-elles directement exposées à Internet, ou se trouvent-elles derrière des proxys inversés, des passerelles API ou d'autres couches de sécurité ? Bien qu'une défense en profondeur soit toujours recommandée, ne partez pas du principe qu'un WAF ou un proxy inversé vous protège automatiquement contre cette vulnérabilité. La manipulation de requête nécessaire pour exploiter CVE-2025-24813 pourrait très bien passer à travers ces couches.
- Enfin, réfléchissez à ce que vous protégez. Même si vous êtes techniquement vulnérable, le risque réel dépend de ce à quoi un attaquant pourrait avoir accès en contournant vos mesures de sécurité. S'il s'agit d'une interface d'administration donnant accès aux données clients ou aux commandes du système, les enjeux sont considérables. S'il s'agit d'un point de terminaison de surveillance interne qui n'affiche que des métriques anonymisées, l'urgence est différente.
Le but ici n'est pas de minimiser la vulnérabilité ni de vous dissuader d'appliquer les correctifs. Il s'agit plutôt de bien cerner votre profil de risque afin de pouvoir hiérarchiser correctement les mesures correctives, surtout si vous gérez des dizaines, voire des centaines d'instances Tomcat.
Mesures d'atténuation et de correction
La solution principale et recommandée pour la vulnérabilité CVE-2025-24813 est simple : passer à une version corrigée d'Apache Tomcat. Mais comme le savent tous ceux qui ont déjà géré des déploiements Tomcat en production, « il suffit de mettre à jour » est plus facile à dire qu'à faire.
Une mise à niveau sans heurts
Si vous pouvez effectuer une mise à niveau sans problème, voici à quoi cela ressemble :
- Identifiez la version actuelle de Tomcat sur tous les déploiements. Utilisez catalina.sh version ou vérifiez le numéro de version dans le répertoire d'installation de Tomcat. Ne vous fiez pas à la documentation ou aux guides d'exploitation qui pourraient être obsolètes.
- Téléchargez la version corrigée appropriée sur le site officiel d'Apache Tomcat. Pour Tomcat 11, téléchargez la version 11.0.3 ou une version ultérieure. Pour la version 10.1, téléchargez la version 10.1.35 ou une version ultérieure. Pour la version 9.0, téléchargez la version 9.0.99 ou une version ultérieure. Si vous utilisez encore Tomcat 8.5, il n'existe pas de correctif communautaire – consultez la section « Lorsque la mise à niveau n'est pas immédiatement possible » ci-dessous. Téléchargez toujours depuis les sources officielles, jamais depuis des miroirs aléatoires ou des référentiels tiers.
- Testez d'abord la mise à jour dans un environnement hors production. Il ne s'agit pas d'une paranoïa inutile, mais d'une mesure de sécurité élémentaire. Les mises à niveau de Tomcat entraînent parfois des changements de comportement ou des modifications des performances qui peuvent vous surprendre. Vérifiez que vos applications fonctionnent toujours, que les indicateurs de performance sont satisfaisants et que les intégrations de surveillance ou de journalisation fonctionnent toujours.
- Planifiez le déploiement en production. Tenez compte de vos fenêtres de déploiement, des modèles de trafic et des procédures de retour en arrière. Si vous exécutez Tomcat derrière un équilibreur de charge, vous pouvez mettre à niveau les instances une par une. Si vous évoluez dans un environnement plus contraignant, vous aurez peut-être besoin d'une fenêtre de maintenance. Assurez-vous de disposer d'un plan de retour en arrière testé au cas où quelque chose tournerait mal.
- Effectuez la mise à jour et vérifiez que vous utilisez bien la version corrigée. Ne partez pas du principe que la mise à jour a fonctionné : vérifiez bien le numéro de version après le déploiement.
Mesures d'atténuation basées sur la configuration
Même si la mise à jour constitue la solution adéquate, certains ajustements de configuration peuvent vous permettre de réduire votre vulnérabilité à court terme. Vérifiez vos règles de sécurité afin de vous assurer qu’elles sont aussi précises et restrictives que possible. Des modèles d’URL trop généraux ou des règles mal définies peuvent accroître votre surface d’attaque.
Envisagez de mettre en place des couches d'authentification supplémentaires au niveau du proxy inverse ou de la passerelle API si votre architecture comprend ces composants. Encore une fois, cela ne remplace pas l'application des correctifs, mais renforce la sécurité en profondeur.
Si vous exploitez des instances Tomcat hébergeant plusieurs applications web, vérifiez quelles applications sont déployées et si elles sont toutes nécessaires. Réduire le nombre d'applications déployées permet de réduire la surface d'attaque potentielle.
Considérations opérationnelles
Voici quelques points pratiques à prendre en compte lors de l'installation des correctifs :
- Conditions requises pour le redémarrage. La mise à niveau de Tomcat nécessite un redémarrage. Cela implique un temps d'arrêt pour vos applications, à moins que vous n'ayez conçu une architecture permettant des déploiements sans interruption de service. Prévoyez en conséquence.
- Compatibilité des fichiers de configuration. La plupart des mises à niveau de Tomcat sont rétrocompatibles avec les fichiers de configuration existants, mais pas toujours. Prêtez une attention particulière à toutes les personnalisations que vous avez apportées au fichier server.xmlet web.xmlou d’autres fichiers de configuration.
- Dépendances liées à la version de la JVM. Les différentes versions de Tomcat ont des exigences différentes en matière de version Java. Tomcat 10.1 nécessite Java 11. Tomcat 11 nécessite Java 17 ou une version ultérieure. Si vous effectuez une mise à niveau à partir d'une version antérieure de Tomcat, vous devrez peut-être également mettre à niveau votre JVM, ce qui ajoute à la complexité.
- Compatibilité des bibliothèques et des connecteurs. Si vous utilisez des pilotes JDBC, des connecteurs JMS ou d'autres bibliothèques avec Tomcat, vérifiez qu'ils sont compatibles avec la version vers laquelle vous effectuez la mise à niveau. Ceci est particulièrement important pour les applications d'entreprise plus anciennes.
- Agents de surveillance et d'APM. Si vous utilisez des agents de surveillance ou des outils APM qui s'intègrent à Tomcat, vérifiez qu'ils fonctionnent toujours après la mise à niveau. Certains agents sont sensibles aux changements de version de Tomcat.
Lorsque la mise à niveau n'est pas immédiatement envisageable
Soyons réalistes : toutes les entreprises ne peuvent pas tout laisser tomber pour mettre à jour l’ensemble de leurs instances Tomcat dès la publication d’une vulnérabilité CVE. Parfois, vous avez affaire à des applications fournies par des éditeurs qui intègrent des versions spécifiques de Tomcat et ne prennent pas en charge les versions plus récentes. Parfois, vous exécutez des applications héritées sur d’anciennes branches de Tomcat dont la mise à niveau nécessiterait des tests et une validation approfondis. Parfois, vous disposez simplement de ressources limitées et devez donner la priorité aux instances les plus critiques.
Pour les équipes qui utilisent d'anciennes versions de Tomcat ne pouvant pas être mises à niveau immédiatement, il existe des options de support de sécurité prolongé permettant de pallier cette lacune. Des services tels que l'Endless Lifecycle Support (ELS) de TuxCare fournissent des correctifs de sécurité continus pour les versions de logiciels en fin de vie, y compris les anciennes versions de Tomcat qui ne reçoivent plus de mises à jour de la part du projet Apache.
Cela ne remplace pas l'application des correctifs appropriés ni la mise à niveau vers les versions actuelles. Il s'agit d'une solution pragmatique de réduction des risques qui peut s'inscrire dans un plan de correction par étapes. Si vous exploitez des instances de Tomcat 8.0 ou 7.0 qui ne peuvent pas être migrées immédiatement, le support étendu permet de protéger ces systèmes contre les vulnérabilités connues pendant que vous procédez à la mise à niveau selon un calendrier réaliste.
L'essentiel est d'agir de manière réfléchie. Si vous bénéficiez d'un support étendu, prévoyez clairement comment passer, à terme, aux versions actuelles de Tomcat. Ne laissez pas le support étendu devenir un prétexte pour repousser indéfiniment la gestion de la dette technique.
Au-delà de cette vulnérabilité CVE : mettre en place des déploiements Tomcat résilients
La faille CVE-2025-24813 est un cas particulier, mais elle s'inscrit dans une tendance plus générale. Des failles de sécurité dans Tomcat sont régulièrement découvertes, et ce sera toujours le cas. La question n'est pas de savoir si vous devrez à nouveau appliquer un correctif à Tomcat, mais plutôt avec quelle rapidité et quelle facilité vous pourrez le faire lorsque la prochaine faille CVE sera signalée.
Cela implique de mettre en place des pratiques opérationnelles favorisant l'application rapide des correctifs : tenir à jour un inventaire précis de tous les déploiements Tomcat, disposer de procédures de mise à niveau testées, effectuer régulièrement des analyses de vulnérabilité et maintenir des environnements de préproduction fidèles à l'environnement de production pour tester les mises à jour.
Cela implique également de faire des choix architecturaux qui favorisent la sécurité : faire tourner les instances Tomcat derrière des proxys inversés, mettre en place une segmentation du réseau, utiliser une orchestration de conteneurs qui facilite les mises à jour progressives, et respecter le principe du moindre privilège pour les autorisations des processus Tomcat.
Cela signifie aussi qu'il faut se tenir informé. Inscrivez-vous à la liste de diffusion dédiée à la sécurité d'Apache Tomcat. Surveillez les bases de données CVE pour détecter les failles liées à Tomcat. N'attendez pas qu'une faille soit rendue publique pour commencer à planifier votre réaction.
Passer à l'action
La vulnérabilité CVE-2025-24813 est grave, mais elle peut être corrigée. Les correctifs existent, les mesures d'atténuation sont claires et les conditions d'exploitation sont suffisamment précises pour vous permettre de prendre des décisions éclairées quant à la priorité à lui accorder.
Si vous utilisez des versions de Tomcat concernées et que vous recourez à des contraintes de sécurité pour protéger vos ressources, considérez cette mise à jour comme une tâche hautement prioritaire. Testez la mise à niveau, planifiez son déploiement et veillez à mettre à jour ces instances. Si vous utilisez des versions plus anciennes de Tomcat qui ne bénéficieront plus de correctifs, évaluez les possibilités de prolongation du support ou accélérez vos projets de migration.
La pire réaction face à la vulnérabilité CVE-2025-24813 serait de l'ignorer en espérant qu'elle n'ait pas de conséquences. La meilleure réaction consiste à évaluer votre exposition au risque, à hiérarchiser vos mesures correctives et à appliquer vos correctifs de manière systématique.
Vos instances Tomcat font partie intégrante de votre infrastructure applicative. Assurer leur sécurité n'est pas une tâche facultative que l'on peut accomplir quand on a un moment de libre. Il s'agit d'une responsabilité opérationnelle fondamentale qui mérite qu'on y consacre du temps, de l'attention et des ressources.
