CVE-2026-34486 : RCE non-auth Apache Tomcat Tribes (cluster)

Les faits

La fondation Apache Software Foundation a publié une mise à jour de sécurité corrigeant CVE-2026-34486, une vulnérabilité critique d'exécution de code à distance non authentifiée affectant le composant Tomcat Tribes utilisé pour le clustering. La faille est notée CVSS 9.8 (vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) avec un score d'exploitabilité maximal : aucune authentification, aucune interaction utilisateur, aucune condition spéciale n'est requise. D'après l'advisory officiel Tomcat, plus de 4,7 millions d'instances Tomcat sont exposées à internet selon les estimations des chercheurs de Striga.ai à l'origine de la découverte.

La chronologie de la découverte est paradoxale : la vulnérabilité ne provient pas d'un bug initial, mais d'une régression introduite par un correctif antérieur. Une mise à jour publiée en mars 2026, destinée à corriger une faille de type padding-oracle dans l'EncryptInterceptor, a déplacé une ligne de code en dehors d'un bloc try/catch. Cette modification anodine a transformé l'interception en "fail-open" : lorsque la déchiffrement d'un message de cluster échoue, l'interceptor ne rejette plus le paquet et le transmet à la chaîne de traitement suivante, qui se trouve être la routine Java native de désérialisation. Les chercheurs ont publié une analyse détaillée intitulée "Fail Open, Game Over" décrivant ce mécanisme.

Du point de vue technique, la chaîne d'exploitation s'appuie sur trois éléments. Premièrement, le composant Tomcat Tribes est utilisé par les administrateurs qui activent la réplication de session entre plusieurs nœuds Tomcat — typique dans les déploiements à haute disponibilité. Deuxièmement, le port d'écoute par défaut (4000/TCP) est lié à l'interface réseau primaire, et non à localhost, ce qui le rend potentiellement accessible depuis n'importe quel sous-réseau autorisé à atteindre la machine. Troisièmement, l'attaquant envoie un payload sérialisé Java arbitraire vers ce port ; l'EncryptInterceptor échoue à le déchiffrer mais le transmet à ObjectInputStream.readObject() sans filtrage.

L'exploitation requiert qu'une "gadget chain" Java soit présente dans le classpath de l'application — typiquement Commons-Collections, Spring, Hibernate ou tout autre framework largement utilisé. Or, ces dépendances sont quasi-omniprésentes dans les applications JEE modernes. Des PoC publics ont déjà été publiés sur GitHub, notamment par les comptes striga-ai et 404-src, ainsi qu'une vidéo de démonstration par le chercheur Karczewski. Le PoC fonctionne contre Tomcat 10.1.53 avec Commons-Collections 3.2.1 et permet l'exécution de commandes shell arbitraires sous le contexte du processus Tomcat (typiquement utilisateur "tomcat" mais souvent root en environnements mal configurés).

D'après la base NVD/NIST et les advisories tiers (SocRadar, Cyber Kendra, Positive Technologies dbugs), la faille a été divulguée fin avril 2026 après coordination avec l'équipe Tomcat. Les versions corrigées 11.0.21, 10.1.54 et 9.0.117 ont été publiées simultanément. Toutefois, contrairement à un patch classique, ce correctif rétablit simplement le comportement "fail-closed" du code antérieur à la régression : les administrateurs ayant ignoré la chaîne de mises à jour des dernières semaines pourraient se retrouver doublement exposés.

L'exploitation in-the-wild n'est pas confirmée publiquement à la date de publication, mais les conditions sont réunies pour une vague d'attaques imminente : la simplicité de l'exploitation (un seul paquet réseau), la maturité des outils de désérialisation Java (ysoserial), la base massive de serveurs Tomcat exposés, et la publication de PoC fonctionnels. Le CERT-FR n'a pas encore publié d'alerte dédiée mais l'avis CERTFR-2026-AVI couvre les vulnérabilités Apache du mois en cours.

Les opérateurs de ransomware sont historiquement très réactifs aux failles de désérialisation Java — Cl0p, BlackCat et LockBit 4.0 ont intégré dans leurs kits d'anciennes vulnérabilités similaires comme CVE-2023-46604 (ActiveMQ). Les groupes étatiques chinois APT41 et russes Sandworm sont également connus pour exploiter ce type de vecteur dans leurs campagnes de positionnement préalable. La fenêtre entre divulgation et exploitation massive est généralement de 5 à 15 jours pour ce type de faille.

À noter : l'EncryptInterceptor n'est utilisé que si l'administrateur l'a explicitement configuré dans le fichier server.xml, généralement pour chiffrer le trafic de réplication de session entre nœuds. Paradoxalement, les déploiements les plus "sécurisés" — ceux qui ont activé le chiffrement inter-cluster — sont précisément ceux affectés par cette régression. Les configurations standards sans EncryptInterceptor ne sont pas vulnérables à CVE-2026-34486.

Impact et exposition

Les organisations exposées sont celles ayant déployé Apache Tomcat 11.0.19+, 10.1.53+ ou 9.0.116+ avec le clustering activé et l'EncryptInterceptor configuré. Les environnements typiques incluent : applications JEE à haute disponibilité, plateformes e-commerce avec sessions répliquées, applications bancaires Spring Boot empaquetées avec Tomcat embarqué, applications gouvernementales et hospitalières, et de nombreuses solutions SaaS construites sur la pile Java.

La surface d'attaque est conditionnée par l'exposition du port 4000/TCP (ou port custom configuré dans server.xml). En pratique, ce port est rarement exposé directement à internet — mais il est très souvent accessible depuis l'ensemble du LAN, voire depuis des sous-réseaux mal segmentés (zone DMZ, environnements de pré-production partagés, etc.). Un attaquant ayant déjà obtenu un point d'entrée minimal (compromission d'un poste utilisateur, accès VPN volé) peut donc pivoter vers le cluster Tomcat depuis l'intérieur du périmètre.

La gravité réelle dépend également des gadget chains disponibles. Tomcat lui-même est désormais shipped avec un filtre anti-désérialisation par défaut, mais ce filtre est désactivé pour le canal Tribes. Toute application déployée embarquant Commons-Collections, Spring AOP, Hibernate, Groovy ou des centaines d'autres bibliothèques courantes fournit le carburant nécessaire à ysoserial pour construire un payload fonctionnel.

Les secteurs particulièrement exposés sont la finance (applications J2EE legacy), la santé (DMP, dossiers patients), l'administration publique (applications métiers) et les éditeurs SaaS B2B. Aucune exploitation in-the-wild confirmée à ce jour, mais la publication des PoC sur GitHub change radicalement le calcul de risque dans les 7 à 14 prochains jours.

Recommandations immédiates

• Mettre à jour Apache Tomcat vers 11.0.21, 10.1.54 ou 9.0.117 dans les 72 heures — advisory : Apache Tomcat Security 11/10/9 mai 2026.
• En attendant le patch, désactiver l'EncryptInterceptor dans server.xml (commenter la ligne <Interceptor className="...EncryptInterceptor"/>) — le cluster restera fonctionnel sans chiffrement.
• Bloquer le port 4000/TCP (ou port Tribes configuré) au niveau du firewall périmétrique ET inter-VLAN ; ne laisser passer que les IP des nœuds du cluster.
• Activer un filtre de désérialisation Java via la propriété système jdk.serialFilter pour interdire les classes des gadget chains connues (org.apache.commons.collections.*, etc.).
• Surveiller les logs réseau pour tout trafic anormal vers le port 4000 depuis des IP non autorisées (IoC : connexions inattendues depuis hors-cluster).
• Auditer la présence d'applications déployées contenant Commons-Collections 3.x ou 4.x non patchées dans WEB-INF/lib.