Apache à la loupe : PUT partiel de Tomcat et détournement de l’en-tête Camel

Synthèse

En mars 2025, Apache a divulgué la CVE-2025-24813, une vulnérabilité affectant Apache Tomcat. Il s’agit d’une plateforme largement utilisée qui permet aux serveurs web Apache d’exécuter des applications web basées sur Java. Cette faille permet d’exécuter du code à distance et affecte les versions 9.0.0.M1 à 9.0.98, 10.1.0-M1 à 10.1.34 et 11.0.0-M1 à 11.0.2 d’Apache Tomcat.

Le même mois, Apache a révélé deux vulnérabilités supplémentaires dans Apache Camel, un framework intergiciel de routage de messages. Ces vulnérabilités sont les suivantes : CVE-2025-27636 et CVE-2025-29891, deux failles permettant l’exécution de code à distance, affectant Apache Camel versions 4.10.0 à 4.10.1, 4.8.0 à 4.8.4 et 3.10.0 à 3.22.3.

Ces vulnérabilités sont importantes car des millions de développeurs s’appuient sur la plateforme fournie par la Fondation Apache. L’exploitation réussie de ces vulnérabilités peut permettre aux attaquants d’exécuter du code arbitraire avec les privilèges de Tomcat/Camel.

Apache a publié des correctifs, et des chercheurs ont rapidement publié des exploits de type "preuve de concept" (PoC). Des scans et des sondes de serveurs vulnérables ont été observés dans la nature peu après la publication de ces informations. Nous avons confirmé la possibilité d’exécution de code à distance à partir de ces trois vulnérabilités.

Palo Alto Networks a bloqué 125 856 sondes/scans/tentatives d’exploitation liées à ces vulnérabilités en mars 2025. Nous conseillons aux organisations d’appliquer rapidement les correctifs.

Les clients de Palo Alto Networks sont mieux protégés grâce aux produits suivants :

• Le pare-feu nouvelle génération intégrant Advanced Threat Prevention peut aider à identifier et à bloquer le trafic associé
• Cortex Xpanse et le module complémentaire ASM pour Cortex XSIAM peuvent identifier les serveurs Apache Tomcat orientés vers l’extérieur à l’aide de la règle de surface d’attaque "Tomcat Web Server".

Si vous pensez que votre entreprise a pu être compromise ou si vous faites face à une urgence, contactez l’équipe Unit 42 de réponse aux incidents.

Unit 42 - Thématiques connexes	Vulnerabilities, CVE-2025-24813, CVE-2025-27636, CVE-2025-29891

CVE-2025-24813 : Apache Tomcat

Aperçu des vulnérabilités

CVE-2025-24813 est une vulnérabilité dans la fonctionnalité PUT partielle d’Apache Tomcat,qui peut permettre à des attaquants d’écraser des fichiers de session sérialisés sur le disque, conduisant à l’exécution de code arbitraire.

Cette vulnérabilité survient lorsque Tomcat est configuré pour conserver les données de session HTTP, car les systèmes Tomcat sans correctif traitent de manière incorrecte les requêtes PUT partielles contenant l’en-tête Content-Range.

PUT partiel

Le terme "PUT partiel" se réfère à une requête HTTP PUT qui ne met à jour qu’une partie d’une ressource au lieu de la remplacer entièrement. Lorsqu’il est pris en charge, le PUT partiel utilise généralement l’en-tête Content-Range dans une requête HTTP pour spécifier quelle partie de la ressource doit être modifiée.

Cela permet aux clients de télécharger ou d’écraser des segments de ressources par blocs. Un PUT partiel peut être exploité pour effectuer des téléchargements incrémentiels de fichiers, écraser des parties spécifiques de fichiers ou contourner certains contrôles de sécurité s’il n’est pas correctement géré.

Fonctionnalité de persistance de session dans Apache Tomcat

Le gestionnaire de session HTTP d’Apache Tomcat comprend une fonctionnalité de persistance de session. Cette fonctionnalité enregistre les données de session dans un fichier ou une base de données lorsque le serveur est arrêté, et recharge ces données mises en cache lorsque le serveur est redémarré. Les données de session contiennent des informations telles que l’état de connexion et les préférences de l’utilisateur, et cette fonctionnalité permet de préserver les données de session d’un utilisateur lors des redémarrages du serveur.

Tomcat encode ces données de session sauvegardées sous la forme d’un flux d’octets à l’aide d’un processus appelé sérialisation et stocke les données sérialisées dans le système de fichiers local. Il sérialise tous les attributs de la session stockés dans l’objet HttpSession. Cela inclut toutes les données que votre application web place explicitement dans la session en utilisant session.setAttribute(). Les informations sont généralement stockées quelque part dans $TOMCAT_HOME/webapps/ROOT/.

Cependant, les données de session sérialisées sont stockées dans le même répertoire que celui utilisé par la fonction executePartialPut de Tomcat. Les utilisateurs peuvent élaborer des requêtes HTTP pour contrôler l’identifiant de session et le nom de fichier des données mises en cache dans ce répertoire. Cela pourrait permettre à un attaquant de définir intentionnellement l’identifiant de session pour qu’il corresponde au nom de fichier mis en cache d’un code malveillant précédemment enregistré dans le cache. Cela peut entraîner la désérialisation du fichier mis en cache, ce qui déclenche le code malveillant intégré.

Conditions préalables

L’en-tête Content-Range est souvent utilisé pour les mises à jour partielles. Cet en-tête indique que le corps de la demande contient une partie de la ressource plutôt que la ressource entière. Si une requête HTTP PUT contient un en-tête Content-Range, Tomcat enregistre le contenu (corps) de la requête PUT à l’emplacement du cache. L’extrait de code suivant montre que Tomcat enregistre les données d’une requête HTTP PUT contenant du contenu.

Une configuration Tomcat vulnérable doit avoir deux conditions préalables pour exploiter cette vulnérabilité :

1. Un paramètre en lecture seule désactivé dans le fichier de configuration de Tomcat à $TOMCAT_HOME/conf/web.xml. La section du fichier web.xml qui contient un paramètre désactivé en lecture seule est la suivante.

Exploitation de la vulnérabilité

Nous avons testé l’exploitation de la CVE-2025-24813 en mars 2025. L’exploitation de cette vulnérabilité se fait en deux étapes :

• Tout d’abord, préparez le payload en le terminant en tant que fichier par une requête HTTP PUT avec une plage de contenu et un nom de fichier auto-défini dans l’URL. Ce fichier contient du code malveillant sérialisé en vue d’une désérialisation ultérieure.
• Ensuite, déclenchez l’exploit en envoyant une requête HTTP GET supplémentaire contenant un cookie composé de JSESSIONID= immédiatement suivi du nom de fichier défini par l’utilisateur et précédé d’un point. Dans ce cas, le format de la ligne de cookie est le suivant : Cookie: "JSESSIONID=.[nom de fichier]", comme l’indique la figure 1 ci-dessous. Cela déclenchera la désérialisation du cache pour exécuter le code malveillant.

Étape 1 : Préproduction du code malveillant sérialisé

Cette première étape consiste à envoyer un fichier de code malveillant sérialisé dans le corps d’une requête HTTP PUT. Apache Tomcat mettra en cache le code malveillant en tant que fichier de session sur le système de fichiers local, puisque le nom du fichier dans l’URI se termine par .session, comme le montre la figure 2 dans la ligne d’en-tête PUT.

La figure 2 montre la requête PUT de la première étape avec gopan.session comme nom de fichier. Le format de cette requête HTTP PUT du trafic est le suivant :

PUT /[nom du fichier].session HTTP/1.1

Étape 2 : Déclenchement de l’exploit

La deuxième étape consiste à envoyer une requête HTTP GET de suivi pour déclencher l’exploit et exécuter le code malveillant. La figure 3 montre la requête HTTP GET avec la valeur du cookie JSESSIONID utilisée à l’étape précédente. Le format de ce cookie est le suivant :

Cookie: JSESSIONID=.[nom du fichier]

La valeur du cookie pour cet exploit utilise un point (.) avant la valeur du nom de fichier du JSESSIONID. Ce point initial conduira Tomcat à enregistrer le fichier de session avec le point initial.

Analyses du code source des pages web

Comment Tomcat met en cache le corps du message PUT dans un fichier

Comme le montre la figure 5, Tomcat vérifie d’abord si l’indicateur "readonly" est activé dans le fichier de configuration. Si c’est le cas, Tomcat n’écrit aucun code dans le cache, y compris le code malveillant.

• Si l’option readonly n’est pas activée, Tomcat vérifie également le champ Content-Range dans l’en-tête HTTP.
• Si la demande ne comporte pas d’en-tête Content-Range, Tomcat met fin au processus.
• Si la requête comporte un en-tête Content-Range, Tomcat enregistre les données de session de la requête HTTP PUT, en l’occurrence gopan.session, à deux endroits, comme le montre la figure 5.
  • Le premier est enregistré comme un fichier cache normal sous $TOMCAT_HOME/webapps/ROOT/ sans être précédé de point.
  • Le second est enregistré dans un fichier temporaire avec un point au début sous le répertoire de travail $TOMCAT_HOME/work/Catalina/localhost/ROOT/.

Il est important de noter que lorsque Tomcat restaure une session, il charge également le fichier de session mis en cache dans le même dossier de travail.

Les figures 6 et 7 montrent des segments de code du servlet Java par défaut que Tomcat utilise pour charger les fichiers de session mis en cache lors de la restauration d’une session, à l’adresse java/org/apache/catalina/servlets/DefaultServlet.java. Les commentaires en jaune décrivent les mesures exécutées par le code.

Comment la vulnérabilité est déclenchée par une requête HTTP

Lorsque Tomcat reçoit une requête HTTP avec un identifiant de session, si la persistance de session est activée dans la configuration, il essaiera de trouver la session dans la mémoire. Si Tomcat ne trouve pas la session en mémoire, il la restaure à partir du fichier cache sauvegardé. À ce stade, Tomcat désérialise le fichier de session, comme le montre la figure 8.

La figure 8 illustre le flux de gestion des sessions de Tomcat. Le code qui localise les sessions, les charge à partir du disque et désérialise leur contenu est mis en œuvre dans les fichiers suivants :

• java/org/apache/catalina/session/PersistentManagerBase.java
• java/org/apache/catalina/Store.java
• java/org/apache/catalina/session/FileStore.java

La figure 9 montre un segment de code de java/org/apache/catalina/session/PersistentManagerBase.java qui demande à Tomcat de trouver un fichier pour les données de session, si celles-ci ne sont pas disponibles en mémoire.

Les figures 10 et 11 montrent des segments de code du même fichier PersistentManagerBase.java qui illustrent le chargement des données de session à partir d’un fichier cache sauvegardé.

Comme le montre la figure 11, store.load(id) déclenche la désérialisation, ce qui active le code malveillant précédemment intégré au fichier par l’attaquant. Il en résulte une exécution de code arbitraire.

L’examen de ce code source révèle tout d’abord comment Tomcat enregistre les données de session à partir d’une requête HTTP PUT, un processus par lequel un attaquant peut stocker du code malveillant. Cet examen permet également de comprendre comment un exploit pour la vulnérabilité CVE-2025-24813 peut être déclenché par une simple requête HTTP GET de suivi.

Cependant, Tomcat n’est pas le seul logiciel Apache pour lequel nous avons vu des tentatives d’exploitation dans la nature. Nous avons également constaté des tentatives d’exploitation de deux vulnérabilités dans Apache Camel.

CVE-2025-27636 et CVE-2025-29891 : Apache Camel

Présentation d’Apache Camel

Apache Camel est un cadriciel d’intégration open-source qui permet aux développeurs de connecter différents systèmes de manière fiable et évolutive. Grâce à Camel, les développeurs peuvent définir des règles de routage et de médiation dans une variété de langages spécifiques à un domaine afin d’intégrer divers systèmes et applications. Apache Camel prend en charge un large éventail de protocoles et de technologies.

La plupart des gestionnaires de messages Camel sont fournis sous forme de paquets Java, ce qui permet au développeur de choisir les paquets à inclure dans son produit.

Détails de l’exploitation

Qu’il soit chiffré ou non, le protocole HTTP est une méthode courante pour envoyer des données sur Internet. Alors que Camel utilise différents types de composants HTTP tels que Jetty et Netty, Camel achemine finalement les messages HTTP analysés vers ses composants principaux, connus sous le nom de camel-core pour un traitement ultérieur.

Pour faciliter l’échange de données entre Camel et ses composants HTTP tels que Jetty et Netty, les développeurs ont conçu une méthode utilisant des paires clé-valeur pour stocker des informations contextuelles importantes, telles que le code de réponse HTTP. Étant donné que les en-têtes HTTP sont utilisés lors du traitement, Camel les stocke également dans la même paire clé-valeur. Pour éviter les conflits entre les informations contextuelles internes et les données externes, les développeurs de Camel ont ajouté un préfixe Camel à toutes les clés contextuelles internes et ont mis en place un filtre pour empêcher les en-têtes externes de poser problème (figure 12).

Cependant, comme le filtre est sensible à la casse, un attaquant pourrait potentiellement le contourner en modifiant la casse des en-têtes.

Analyses du code source des pages web

Par défaut, Camel enregistre le gestionnaire de filtre d’en-tête par défaut. Il demande au filtre d’ignorer toutes les lignes d’en-tête qui commencent par Camel, camel et org.apache.camel. Le code correspondant se trouve dans components/camel-http-base/src/main/java/org/apache/camel/http/base/HttpHeaderFilterStrategy.java, et la figure 13 montre le segment correspondant.

Camel énumère les en-têtes des requêtes HTTP, exécute la fonction applyFilterToExternalHeaders et écrit les en-têtes dans une carte interne en utilisant components/camel-http-common/src/main/java/org/apache/camel/http/common/DefaultHttpBinding.java comme l’indique la figure 14 ci-dessous.

La logique de filtrage de l’en-tête effectue différentes correspondances en fonction de la configuration de Camel. Par défaut, Camel n’utilise tryHeaderMatch que pour vérifier le début de l’en-tête. Cela se fait par l’intermédiaire de core/camel-support/src/main/java/org/apache/camel/support/DefaultHeaderFilterStrategy.java, comme le montre la figure 15 ci-dessous.

En supposant qu’un attaquant remplace l’en-tête CAmelExecCommandExecutable en utilisant un A majuscule dans le mot CAmel, et que le développeur utilise le progiciel camel-exec, ce dernier lira la valeur et l’exécutera via components/camel-exec/src/main/java/org/apache/camel/component/exec/impl/DefaultExecBinding.java, comme l’illustre la figure 16 ci-dessous.

Si un développeur a défini ce terminal pour exécuter un fichier exécutable bénin, l’attaquant peut remplacer le terminal par une commande dangereuse, en utilisant un shell inversé (reverse shell). L’attaquant peut potentiellement obtenir un shell inversé par l’exécution de commandes à distance.

Télémétrie

Au cours du mois de mars 2025, notre télémétrie a identifié 125 856 scans, sondes ou tentatives d’exploitation provenant de plus de 70 pays pour la vulnérabilité Tomcat CVE-2025-24813 et les vulnérabilités Camel CVE-2025-27636 et CVE-2025-29891. Comme le montre notre analyse des données dans la figure 17, la fréquence de cette activité a augmenté immédiatement après l’annonce de ces exploits à la mi-mars 2025, atteignant son maximum au cours de la première semaine.

Les données indiquent en outre la présence de scanners automatisés et d’exploits actifs dans la nature.

Payloads des tentatives d’exploitation

Nous avons capturé les payloads que les attaquants ont utilisé jusqu’à présent lors de ces analyses, sondes et tentatives d’exploitation.

La figure 18 montre un exemple de requête HTTP PUT initiale pour une tentative d’exploitation de la vulnérabilité CVE-2025-24813 d’Apache Tomcat. Ce type d’activité est un scan ou une sonde visant à déterminer si un serveur utilise une version vulnérable de Tomcat.

S’il réussit, l’exploit de la figure 20 fait que le serveur victime tente de contacter un serveur de test de sécurité des applications hors bande (OAST).

La figure 19 montre la requête HTTP pour un exploit de la vulnérabilité CVE-2025-27636 d’Apache Camel. En cas de succès, le serveur exécute une commande echo. Il s’agit d’un moyen de tester un serveur utilisant Apache Camel si un attaquant y a déjà accès et peut voir les résultats d’une commande echo.

La figure 20 montre la requête HTTP pour un exploit de la vulnérabilité CVE-2025-29891 d’Apache Camel. Comme la tentative d’exploitation d’Apache Tomcat présentée à la figure 20, cette exploitation d’Apache Camel demanderait au serveur vulnérable de contacter un serveur OAST.

Exploitation de la CVE-2025-24813 dans la nature

Depuis que nous avons mis à jour notre couverture pour cette vulnérabilité, nous avons observé 7 859 tentatives d’exploitation de la vulnérabilité CVE-2025-24813 d’Apache Tomcat.

Dans cette section, nous analysons cette activité sous deux angles : la longueur du nom de la session et la valeur de l’en-tête Content-Range.

Longueur du nom de la session Tomcat

Comme nous l’avons indiqué dans notre analyse précédente, les exploits pour la CVE-2025-24813 utilisent un nom complété par .session dans la requête HTTP initiale. Ce fichier .session contient le code que l’hôte vulnérable exécutera si l’exploit réussit.

La plupart des préfixes de ces noms de session utilisent moins de 10 caractères. Notre télémétrie révèle que les préfixes les plus courants utilisent six caractères comme nom de session, comme l’illustre la figure 21.

Nous avons relevé cette longueur de motif de six caractères dans plus de 6 000 détections. Pourquoi la grande majorité de ces exploits utilisent-ils un nom de session composé d’une chaîne de six caractères ? Ce modèle d’activité est en corrélation avec l’en-tête Content-Range.

En-tête Content-Range de Tomcat

Comme nous l’avons indiqué dans notre analyse du code source de Tomcat pour CVE-2025-24813, l’en-tête HTTP Content-Range est un facteur important dans cette vulnérabilité. La figure 22 regroupe les différentes valeurs de Content-Range.

Notre télémétrie révèle que nous avons noté l’en-tête Content-Range : bytes 0-452/457 dans plus de 6 000 détections. Cette constatation est en corrélation avec le nom de session à six caractères.

Ces deux constatations correspondent à un template pour la CVE-2025-24813 de Nuclei Scanner disponible sur GitHub. La figure 23 met en évidence la corrélation avec nos résultats.

Cela signifie qu’un grand nombre des scans CVE-2025-24813 que nous avons vues jusqu’à présent ont utilisé le scanner Nuclei. C’est logique, puisque Nuclei est un scanner disponible gratuitement sous la licence MIT et que tout le monde peut l’utiliser. Les attaquants et les équipes de sécurité utilisent probablement ce scanner et ce modèle pour vérifier la vulnérabilité.

Conclusion

Les instances Apache Tomcat vulnérables qui autorisent l’écriture de répertoire (désactivée par défaut) et le PUT partiel (activé par défaut) sont vulnérables à la CVE-2025-24813. Les instances Apache Camel vulnérables qui utilisent des composants spécifiques sont vulnérables aux CVE-2025-27636 et CVE-2025-29891.

Ces vulnérabilités présentent un risque important pour la sécurité en raison de leurs failles critiques. Les attaquants peuvent les exploiter par le biais de requêtes HTTP spécifiquement élaborées.

Ces exploits permettent non seulement l’exécution potentielle de codes à distance, mais ils posent également des menaces plus larges telles que les violations de données et les mouvements latéraux au sein du réseau. L’utilisation de Nuclei Scanner pour vérifier cette vulnérabilité souligne la facilité avec laquelle des adversaires moins qualifiés peuvent exploiter ces vulnérabilités, d’où l’importance d’une action immédiate.

Protection et atténuation des risques par Palo Alto Networks

Les clients de Palo Alto Networks sont mieux protégés contre les menaces mentionnées ci-dessus grâce aux produits suivants :

• Le pare-feu nouvelle génération intégrant Advanced Threat Prevention peut identifier et bloquer le trafic associé, en respectant les meilleures pratiques, grâce à la signature de prévention des menaces suivante : 96315
• Cortex Xpanse et le module complémentaire ASM pour Cortex XSIAM peuvent identifier les serveurs Apache Tomcat orientés vers l’extérieur à l’aide de la règle de surface d’attaque "Tomcat Web Server". Les clients peuvent également consulter leurs actifs potentiellement touchés par le biais du Centre de réponse aux menaces.

Si vous pensez que votre entreprise a pu être compromise ou si vous faites face à une urgence, contactez l’équipe Unit 42 de réponse aux incidents ou composez l’un des numéros suivants :

• Amérique du Nord Gratuit : +1 (866) 486-4842 (866.4.UNIT42)
• Royaume-Uni : +44 20 3743 3660
• Europe et Moyen-Orient : +31.20.299.3130
• Asie : +65.6983.8730
• Japon : +81 50 1790 0200
• Australie : +61.2.4062.7950
• Inde : 00080005045107

Palo Alto Networks a partagé ces conclusions avec les autres membres de la Cyber Threat Alliance (CTA). Les membres de la CTA s’appuient sur ces renseignements pour déployer rapidement des mesures de protection auprès de leurs clients et perturber de manière coordonnée les activités des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.

Indicateurs de compromission

CVE-2025-24813

Adresses IP sources observées pour CVE-2025-24813

• 54.193.62[.]84
• 96.113.95[.]10
• 209.189.232[.]134
• 162.241.149[.]101
• 167.172.67[.]75
• 100.65.135[.]245
• 138.197.82[.]147
• 123.16.159[.]102
• 193.53.40[.]18
• 91.208.206[.]203
• 212.56.34[.]85
• 195.164.49[.]70
• 185.91.127[.]9

URL d’activité - CVE-2025-24813

• PUT /qdigu/session
• PUT /UlOLJo.session

Hachage SHA256 des échantillons de payload

• 6a9a0a3f0763a359737da801a48c7a0a7a75d6fa810418216628891893773540
• 6b7912e550c66688c65f8cf8651b638defc4dbeabae5f0f6a23fb20d98333f6b

CVE-2025-27636, CVE-2025-29891

Adresses IP sources observées pour CVE-2025-27636, CVE-2025-29891

• 30.153.178[.]49
• 54.147.173[.]17
• 54.120.8[.]214
• 139.87.112[.]169
• 139.87.112[.]115
• 64.39.98[.]52
• 139.87.112[.]98
• 139.87.113[.]24
• 64.39.98[.]139
• 54.96.66[.]57
• 138.197.82[.]147
• 22.85.196[.]34
• 64.39.98[.]245
• 64.39.98[.]9
• 54.120.8[.]207
• 130.212.99[.]156
• 139.87.112[.]121
• 139.87.113[.]26

En-têtes d’activité pour CVE-2025-27636, CVE-2025-29891

• CAmelHttpResponseCode
• CAmelExecCommandExecutable
• CAmelExecCommandArgs
• CAmelBeanMethodName

Pour aller plus loin

• RFC9110 - Éditeur RFC
• Apache Tomcat - Fondation Apache
• Apache Camel - Fondation Apache
• Modèles de Nuclei - ProjectDiscovery