Une vulnérabilité critique affectant plusieurs produits Atlassian, CVE-2026-21589, est désormais exploitée dans des attaques non authentifiées. La société de cybersécurité Previdian a observé des tentatives d’exploitation frappant son réseau de pièges à poissons (honeypot) dans les deux heures suivant la publication par watchTowr d’une analyse technique et d’une preuve de concept (PoC) publique.
Le problème concerne l’accès arbitraire à des fichiers dans le répertoire web de l’application : un attaquant non authentifié, connaissant le nom exact du fichier et son chemin, peut lire des fichiers protégés.
Atlassian a publié des avertissements le lundi 5 octobre 2026 ; des scans actifs et du trafic d’exploitation ont été confirmés le 7 octobre.
Les versions auto-hébergées (Data Center/server) des produits suivants sont concernées : Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible et Fisheye. Atlassian Cloud n’est pas concerné par cette faille.
La cause racine réside dans une bibliothèque de ressources web partagée qui convertit les doubles deux-points `::` en barres obliques `/`, permettant ainsi des requêtes de traversal de répertoire via des points de terminaison de ressources de plugin dans le contexte d’application Tomcat. watchTowr a confirmé des lectures de fichiers dans Jira, Confluence et Bitbucket, mais n’a pas pu quitter le contexte Tomcat.
Dans les environnements Jira intégrés avec Crowd, la chaîne d'attaque peut s'escalader de manière brutale. Si Crowd est accessible et que l'application dispose des permissions nécessaires, les attaquants peuvent lire les mots de passe en clair des applications depuis le fichier `WEB-INF/classes/crowd.properties` et créer un compte administrateur Jira via l'API de Crowd — prenant ainsi le contrôle de l'identité centralisée, de l'authentification unique (SSO) et des permissions.
La restriction de Crowd à une liste blanche d'adresses IP rend l'exploitation bien plus difficile ; sans cela, les attaquants peuvent devoir pivoter ou exploiter des capacités similaires à SSRF dans Jira/Confluence/Bitbucket pour atteindre Crowd.
Previdian a observé des tentatives depuis des adresses incluant 38.60.157.86, 146.70.187.234 et 159.26.119.225 et recommande de les bloquer. Un modèle Nuclei est déjà disponible, abaissant la barrière pour les scans massifs. watchTowr a également libéré un scanner gratuit pour vérifier si les instances sont vulnérables. Atlassian ne peut pas déterminer si des instances clients individuelles ont déjà été compromises — la mise à jour et la recherche dans les logs sont donc des tâches immédiates, et non une question de "prochain cycle de maintenance".
Pour les organisations nordiques utilisant Jira/Confluence en interne ou exposées sur Internet, le risque est concret : les plateformes de collaboration abritent des sources, des tickets, des données clients et souvent des clés API. Une lecture de fichiers non authentifiée menant à un accès en tant qu’administrateur Crowd représente une voie classique de **zero-day** à un contrôle total une fois une preuve de concept (PoC) rendue publique. Même si Atlassian connaissait la faille avant la correction, la réalité opérationnelle actuelle est une exploitation active.
De nombreuses municipalités, fournisseurs de soins de santé, industries et entreprises logicielles nordiques exploitent encore Jira Data Center en auto-hébergement derrière un VPN — ou ouvertes aux fournisseurs sur Internet. Cela rend la recherche de la vulnérabilité CVE-2026-21589 une campagne à faible effort : un modèle Nuclei combiné à trois adresses IP connues circulent déjà. Attendre la prochaine « fenêtre trimestrielle » expose à des risques d’exfiltration de données et de création d’accès administrateur persistants via Crowd. La réponse aux incidents doit anticiper le pire scénario dès qu’apparaissent des appels suspects `::` dans les logs d’accès.
Historiquement, les vulnérabilités d’Atlassian comme Confluence OGNL ou les contournements d’authentification de Jira ont été massivement exploitées dans les jours suivant la publication d’un PoC. Cette fois, la lecture de fichiers peut sembler « limitée » — jusqu’à ce que les propriétés Crowd soient lues. C’est pourquoi les mesures de mitigation recommandées dans les avis (WAF, RewriteValve, listes blanches d’IP) doivent être considérées comme des contrôles temporaires, et non comme un substitut à la mise à jour. Les organisations qui ont déjà appliqué les correctifs doivent tout de même rechercher les IOCs (Indicateurs de Compromission) : nouveaux utilisateurs administrateurs, modifications des mappings de groupes et appels inhabituels à l’API Crowd.
**Que doivent faire les responsables IT et sécurité maintenant**
Installez immédiatement les mises à jour de sécurité d’Atlassian pour tous les produits Data Center affectés. Restreignez l’accès externe, ajoutez des règles WAF/proxy contre les motifs de parcours, et pour Confluence/Jira/Bamboo/Crowd, appliquez les règles RewriteValve de Tomcat comme indiqué dans les avis ; pour Bitbucket, utilisez la réécriture d’URL. Examinez les logs à la recherche d’appels suspects de ressources de plugins avec `::`, de nouveaux comptes administrateurs Crowd/Jira et de lectures inhabituelles de WEB-INF. Considérez tout signe d’exploitation comme une compromission complète de la chaîne intégrée à Crowd : faites tourner les secrets et auditez les utilisateurs et permissions. Exécutez le scanner watchTowr sur les environnements de recette et de production, et documentez les versions en service avant et après la mise à jour.