Apache ActiveMQ CVE-2026-34197 : 6 400 serveurs exposés

Ce qui s'est passé

Ajoutée cette semaine au catalogue Known Exploited Vulnerabilities (KEV) de la CISA, la faille Apache ActiveMQ CVE-2026-34197 voit son exploitation active en conditions réelles officiellement confirmée. Corrigée discrètement par l'éditeur le 30 mars 2026, elle affecte ActiveMQ Classic, broker de messagerie JMS massivement déployé dans les architectures d'entreprise pour le découplage applicatif et le traitement asynchrone des flux. Nos relevés recensent près de 6 400 instances exposées sur Internet, dont une part significative en Europe occidentale, toujours en attente de correctif. Les serveurs vulnérables offrent aux attaquants un point d'entrée privilégié vers le cœur du système d'information : les brokers de messages transitent des données métier sensibles et disposent souvent d'accès réseau étendus. Les équipes sécurité doivent traiter cette vulnérabilité en priorité absolue, l'inscription au KEV imposant par ailleurs des délais réglementaires stricts aux administrations concernées.

Un scan Shodan récent recense plus de 6 400 adresses IP exposant un ActiveMQ vulnérable, principalement en Asie (2 925), en Amérique du Nord (1 409) et en Europe (1 334). Le facteur aggravant : la vulnérabilité exige en théorie des identifiants, mais le couple par défaut admin:admin reste massivement en place. Pis encore, les versions 6.0.0 à 6.1.1 cumulent une seconde faille (CVE-2024-32114) qui expose Jolokia sans authentification — transformant CVE-2026-34197 en RCE non authentifiée sur ces déploiements, selon l'analyse de The Register.

Pourquoi c'est important

ActiveMQ est un composant d'infrastructure discret mais critique : il orchestre souvent des files de messages bancaires, logistiques ou industrielles. Une compromission du broker donne à l'attaquant un accès pivot vers tous les producteurs et consommateurs connectés, avec une visibilité sur les messages en transit. La faille est qualifiée par Horizon3 de « hiding in plain sight for 13 years » : le code vulnérable existe depuis les premières versions publiques du projet, ce qui signifie que l'exposition réelle dépasse largement les 6 400 serveurs détectés — beaucoup d'instances internes non exposées restent également vulnérables en cas de pivot latéral. Le parallèle avec le récent Spinnaker CVE-2026-32604 et le MCPwn sur nginx-ui est frappant : trois RCE non authentifiées sur des composants DevOps en moins de quinze jours.

La CISA a fixé au 8 mai 2026 la date limite de patch pour les agences fédérales américaines, conformément à la directive BOD 22-01. En Europe, les opérateurs soumis à NIS2 devraient appliquer le correctif dans les 72 heures au titre de l'obligation de diligence, particulièrement pour les secteurs finance, transport et énergie qui utilisent massivement ActiveMQ en backend de leurs files d'événements métier.

Ce qu'il faut retenir

• Migrer immédiatement vers ActiveMQ Classic 6.2.3 ou 5.19.4, les deux seules versions contenant le correctif officiel publié le 30 mars 2026.
• Changer tous les identifiants par défaut du fichier jetty-realm.properties, même sur les instances non exposées à internet, pour bloquer les pivots latéraux.
• Désactiver Jolokia si la console web n'est pas utilisée, ou le restreindre aux IP internes via jolokia-access.xml.

expérience et les traces publiques concernant Jolokia ont largement circulé dans les communautés d'administration système, sans qu'une revue de sécurité systématique n'ait jamais été menée sur cette interface de management. Plusieurs éditeurs de solutions de messagerie ont depuis annoncé des audits internes similaires sur leurs propres API d'administration, signe que l'incident dépasse le seul cas ActiveMQ.

Le précédent le plus proche reste CVE-2023-46604, une faille RCE dans ActiveMQ activement exploitée en 2023 par des opérateurs de ransomware (notamment HelloKitty et TellYouThePass) pour un accès initial. Cette récurrence sur le même composant, à trois ans d'intervalle, illustre la difficulté des équipes IT à maintenir à jour des brokers de messagerie considérés comme des briques d'infrastructure « stables » et donc rarement patchés en priorité par rapport aux serveurs web ou aux passerelles VPN.

Détail technique : vecteur d'attaque et scoring CVSS

La vulnérabilité est notée CVSS 3.1 : 9.8 (Critique) selon le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H dans les scénarios où Jolokia est accessible sans authentification (versions 6.0.0 à 6.1.1 combinées à CVE-2024-32114). Sur les déploiements correctement configurés avec authentification Jolokia active, le score redescend à environ 7.2, la complexité d'exploitation restant néanmoins faible dès lors que les identifiants par défaut n'ont pas été changés. Le chemin d'attaque exploite la méthode exec de l'API Jolokia pour invoquer org.apache.activemq.broker.jmx.BrokerViewMBean#updateClusterClientMetaData ou des opérations équivalentes permettant de rediriger le broker vers un fichier XML de configuration Spring hébergé par l'attaquant, déclenchant l'instanciation d'objets Java arbitraires — un schéma classique de désérialisation détourné.

Versions affectées et mitigation

• Versions vulnérables : ActiveMQ Classic 5.x antérieures à 5.19.4, et 6.x antérieures à 6.2.3 (les branches 6.0.0-6.1.1 étant les plus exposées en raison du cumul avec CVE-2024-32114).
• Mitigation immédiate si le patch ne peut être appliqué sans délai : désactiver le plugin Jolokia dans jetty.xml, ou a minima restreindre l'accès au port 8161 par filtrage réseau (liste blanche d'IP d'administration uniquement).
• Rotation des identifiants : remplacer systématiquement les couples admin:admin par des mots de passe forts, y compris sur les instances jugées « internes » — le scan Shodan démontre que l'exposition réseau involontaire reste fréquente.
• Segmentation : isoler le broker ActiveMQ dans un VLAN dédié sans accès direct depuis Internet, l'interface Jolokia n'ayant vocation qu'à un usage d'administration interne.

Fortinet et Horizon3.ai recommandent également l'inspection des journaux Jetty pour repérer des requêtes POST inhabituelles vers /api/jolokia/exec, ainsi qu'un contrôle d'intégrité des fichiers de configuration du broker (activemq.xml, jetty.xml) pour détecter toute modification non planifiée survenue depuis mi-avril 2026, période de début des campagnes d'exploitation observées.