Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
cve-2026-34486-tomcat_encrypt_bypass_reproduction — Reproduction CVE : cve-2026-34486-tomcat_encrypt_bypass_reproduction | Kitploit
Outils/GitHubGitHub/razureink/cve-2026-34486-tomcat_encrypt_bypass_reproduction
Analyse des VulnérabilitésExploitationExploitation d'Applications WebSécurité WebTests d'IntrusionApprentissage et Éducation
GitHubrazureink/cve-2026-34486-tomcat_encrypt_bypass_reproduction

cve-2026-34486-tomcat_encrypt_bypass_reproduction

Reproduction CVE : cve-2026-34486-tomcat_encrypt_bypass_reproduction

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
Voir le dépôt
il y a 29 joursPas encore vérifié

CVE-2026-34486 : contournement de l'EncryptInterceptor d'Apache Tomcat

ChampValeur
CVECVE-2026-34486
CVSS7.5 ÉLEVÉ
TypeAbsence de chiffrement des données sensibles
ComposantApache Tomcat Cluster EncryptInterceptor
Publié2026

Vue d'ensemble

CVE-2026-34486 est une régression introduite par le correctif incomplet de la CVE-2026-29146. Dans la réplication de cluster d'Apache Tomcat, l'EncryptInterceptor est chargé de chiffrer et d'authentifier les messages du cluster. Un refactoring effectué dans le correctif de la CVE-2026-29146 a déplacé par inadvertance l'appel super.messageReceived(msg) hors du bloc try-catch qui gère les échecs de déchiffrement. Ainsi, lorsqu'un message échoue au déchiffrement (c.-à-d. qu'il est reçu en clair alors que l'intercepteur s'attend à des données chiffrées), le message brut non chiffré est toujours transmis à la chaîne de gestionnaires au lieu d'être rejeté.

Détails techniques

Régression du flux de code

La méthode EncryptInterceptor.messageReceived() est invoquée à l'arrivée d'un message de cluster. Le flux attendu est le suivant :

  1. Recevoir les octets bruts du message
  2. Déchiffrer et valider le message (dans un bloc try-catch)
  3. Si le déchiffrement réussit, appeler super.messageReceived(msg) pour transmettre le message déchiffré
  4. Si le déchiffrement échoue, rejeter le message (ou journaliser une erreur)

Dans les versions vulnérables, la logique de déchiffrement/validation reste encapsulée dans un try-catch, mais la chaîne d'appels a été restructurée de sorte que super.messageReceived(msg) s'exécute en dehors du bloc try-catch qui protège le déchiffrement. La variable msg est déclarée avant le try-catch et affectée à l'intérieur de celui-ci. Lorsque le déchiffrement lève une exception, msg conserve sa valeur initiale (non chiffrée/brute) et le bloc catch ne fait que journaliser l'erreur — il n'effectue pas de retour anticipé. L'exécution se poursuit avec super.messageReceived(msg) et les données brutes non traitées.

Cela signifie qu'un attaquant pouvant atteindre le port de cluster Tomcat peut injecter des messages arbitraires non chiffrés que l'intercepteur acceptera et traitera.

Pseudocode simplifié du bug

root@kitploit:~
public void messageReceived(Message msg) {
    // msg arrives raw
    try {
        // decrypt and populate msg fields
        decrypt(msg);
    } catch (Exception e) {
        log.error("Decryption failed", e);
        // BUG: no return statement here
    }
    // msg is still the original unencrypted object when catch is hit
    super.messageReceived(msg); // outside try-catch → passes raw data
}

Le correctif doit garantir que soit :

  • super.messageReceived(msg) n'est appelé qu'à l'intérieur du bloc try après un déchiffrement réussi, soit
  • Le bloc catch retourne immédiatement afin que le message non chiffré ne soit jamais transmis.

Versions concernées

ProduitVersions
Apache Tomcat 1111.0.20
Apache Tomcat 1010.1.53
Apache Tomcat 99.0.116

Reproduction

Prérequis

  • Une instance Tomcat vulnérable avec la réplication de cluster activée et utilisant l'EncryptInterceptor
  • Un accès réseau au port de cluster Tomcat (généralement 4000 ou 5000, configuré via <Receiver>)
  • Python 3.6+

Étapes

  1. Identifier un membre du cluster Tomcat avec l'EncryptInterceptor configuré dans server.xml.
  2. Déterminer l'adresse et le port du récepteur du cluster.
  3. Exécuter le script d'exploitation pour envoyer un message de cluster brut spécialement conçu.
  4. Observer que le message est accepté et journalisé par le récepteur, contournant ainsi la validation du chiffrement.

PoC

Le script exploit.py de ce répertoire illustre le contournement. Il construit un message de cluster Tomcat minimal (basé sur le format de sérialisation ClusterMessage) et l'envoie directement au port du récepteur sans aucun chiffrement. Un intercepteur vulnérable acceptera et transmettra le message malgré l'absence de chiffrement.

Atténuation

Mettez à jour vers une version corrigée d'Apache Tomcat :

ProduitVersion corrigée
Apache Tomcat 1111.0.21+
Apache Tomcat 1010.1.54+
Apache Tomcat 99.0.117+

Si une mise à jour immédiate n'est pas possible, limitez l'accès réseau au port du cluster Tomcat aux seuls hôtes de confiance (par exemple, via des règles de pare-feu ou en liant le récepteur à une interface de bouclage ou privée).

Références

  • CVE-2026-34486
  • CVE-2026-29146 (vulnérabilité d'origine)
  • Avis de sécurité Apache Tomcat
  • Documentation d'EncryptInterceptor
Télécharger l’outil