La société de cybersécurité Previdian a observé des tentatives d’exploitation de CVE-2026-21589 contre son réseau de honeypots dans les deux heures suivant la publication par watchTowr d’une analyse technique et d’une preuve de concept publique.
Cette vulnérabilité permet d’accéder sans authentification à des fichiers connus situés dans la racine web des applications Atlassian concernées. Elle touche huit familles de produits auto-hébergés, dont Jira, Confluence, Bitbucket et Crowd.
The Hacker News a fait état de 15 tentatives provenant de trois adresses IP. BleepingComputer a relevé les mêmes adresses, sans préciser le nombre de tentatives. Ces données montrent que des honeypots ont fait l’objet de sondages actifs, mais ne confirment pas que des systèmes de clients Atlassian ont été compromis.
BleepingComputer a publié son article le 7 octobre 2026 à 08 h 49. Le média indique que l’avis d’Atlassian a été publié un « lundi », sans en préciser la date. Selon l’article, watchTowr a publié son analyse technique après cet avis, mais rien ne permet d’affirmer que cette analyse a paru le lundi.
L’accès ne requiert pas d’authentification, mais suppose de connaître le nom exact du fichier
CVE-2026-21589 est une vulnérabilité d’accès arbitraire à des fichiers qui touche les produits auto-hébergés suivants :
- Bitbucket Data Center
- Confluence Data Center
- Jira Service Management Data Center
- Jira Software Data Center
- Bamboo Data Center
- Crowd Data Center
- Crucible
- Fisheye
Aucun compte n’est nécessaire pour l’exploiter. Il faut toutefois connaître le nom exact et l’emplacement du fichier ciblé, car la faille ne permet ni de lister ni d’énumérer les répertoires.
Cette contrainte limite les possibilités de découverte par la vulnérabilité elle-même, mais n’empêche pas les attaquants de demander des fichiers d’application dont le nom et l’emplacement sont prévisibles. Les conséquences dépendent des fichiers présents dans chaque configuration et de leur éventuel contenu en identifiants, jetons, clés ou autres données d’authentification.
The Hacker News a indiqué un score CVSS de 9,3. D’après les informations NVD fournies, la vulnérabilité est classée CWE-552, mais aucun vecteur CVSS n’est indiqué.
Les données NVD vérifiées précisent les versions d’introduction pour quatre des huit familles concernées :
- Bitbucket Data Center : introduite à partir de la version
4.6.0 - Confluence Data Center : introduite à partir de la version
5.10.0 - Crowd Data Center : introduite à partir de la version
2.11.0 - Jira Software Data Center : introduite à partir de la version
7.1.0
Ces entrées ne constituent pas une liste exhaustive des versions vulnérables pour chaque produit ou branche maintenue. Les administrateurs doivent appliquer les versions corrigées correspondant à leur déploiement, sans extrapoler la couverture aux quatre autres familles.
Atlassian a indiqué que les produits concernés d’Atlassian Cloud avaient été corrigés. Les articles disponibles ne précisent pas quels produits Cloud sont concernés.
La conversion du chemin de ressource produit la séquence de traversée
L’analyse technique relie la faille à une bibliothèque partagée de ressources web d’Atlassian. Selon les chercheurs, cette bibliothèque convertit les doubles deux-points :: en barres obliques.
Une chaîne de ressource spécialement conçue peut ainsi devenir un chemin de traversée lors de son traitement. Par exemple :
..::..::..::..::WEB-INF::web.xml
peut être convertie en :
../../../../WEB-INF/web.xml
watchTowr a combiné ce comportement avec les points d’accès aux ressources des extensions Atlassian. La technique exploite le chemin et la barre oblique finale associés à une ressource d’extension pour demander un autre fichier dans l’application.
The Hacker News a publié cet exemple visant le fichier WEB-INF/web.xml de Jira :
GET /download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: {{Jira-Hostname}}
La requête ne nécessite aucune authentification. Pour aboutir, l’attaquant doit toutefois connaître un chemin et un nom de fichier valides.
D’après BleepingComputer, watchTowr a vérifié la lecture de fichiers dans Jira, Confluence et Bitbucket. La technique présentée par les chercheurs ne permettait pas de sortir du contexte de l’application Tomcat.
Cette limite s’applique à la méthode testée par watchTowr. Les éléments disponibles ne permettent pas d’établir que toutes les méthodes d’exploitation possibles sont soumises à la même contrainte.
Les déploiements intégrés à Crowd présentent un risque d’escalade sous certaines conditions
La vulnérabilité permet avant tout d’accéder à certains fichiers situés dans la racine web de l’application. Les conséquences peuvent être plus graves si un fichier lisible contient des identifiants réutilisables ailleurs.
Les chercheurs ont notamment signalé le fichier WEB-INF/classes/crowd.properties dans les environnements Jira intégrés à Crowd. Selon BleepingComputer, ce fichier peut contenir en clair les identifiants de l’application utilisés par le système de gestion des identités Crowd.
Si ces identifiants sont valides, que Crowd est accessible et que l’application concernée dispose des autorisations suffisantes, un attaquant pourrait utiliser l’API Crowd pour créer un compte administrateur Jira. Un accès administrateur à Crowd pourrait également permettre de créer de nouveaux utilisateurs et de modifier les autorisations existantes.
Plusieurs conditions doivent être réunies pour passer de la lecture du fichier à cette escalade. Crowd doit être accessible depuis un système contrôlé par l’attaquant, directement ou par un autre biais. Selon les chercheurs, l’attaquant pourrait devoir transiter par une autre machine ou exploiter une fonctionnalité de type SSRF dans Jira, Confluence ou Bitbucket pour joindre Crowd.
D’après les recherches rapportées par BleepingComputer, restreindre l’accès à Crowd à une liste d’adresses IP autorisées compliquerait considérablement cette attaque.
Il s’agit de chaînes d’attaque conditionnelles, présentées ou décrites par les chercheurs. Rien ne prouve qu’une telle escalade ait eu lieu lors de l’activité observée sur les honeypots ni qu’un compte administrateur Jira d’un client ait été créé.
Atlassian a indiqué ne pas être en mesure de déterminer si des instances de clients avaient été compromises.
Les données des honeypots révèlent trois adresses à l’origine des sondages
Previdian a indiqué que ses honeypots avaient commencé à recevoir des tentatives d’exploitation dans les deux heures suivant la publication par watchTowr de son analyse et de sa PoC publique.
The Hacker News a fait état de 15 tentatives provenant de trois adresses IP distinctes. Selon le média, ces adresses se trouvaient au Japon et aux États-Unis, sans préciser le pays associé à chacune.
Les adresses signalées sont les suivantes :
38.60.157[.]86146.70.187[.]234159.26.119[.]225
BleepingComputer a publié les mêmes trois indicateurs et indiqué que Previdian recommandait de les bloquer, sans toutefois préciser le nombre de tentatives.
Le blocage de ces adresses permet de filtrer les sources déjà observées par Previdian. Il ne protège pas contre les tentatives provenant d’autres infrastructures et ne doit pas se substituer à une mise à jour ou au filtrage des schémas de traversée.
Ryan Dewhurst, de Previdian, s’attendait à une hausse de l’activité, compte tenu de la disponibilité des détails techniques, d’une PoC publique et d’un modèle de scan Nuclei couvrant un large éventail de produits. Il s’agissait d’une prévision, et non de la confirmation d’une hausse ultérieure des tentatives d’exploitation.
Versions corrigées et mesures temporaires
Atlassian a recommandé aux administrateurs de déploiements auto-hébergés d’installer les mises à jour de sécurité disponibles. Les versions corrigées signalées sont les suivantes :
| Produit | Versions corrigées signalées |
|---|---|
| Bitbucket Data Center | 9.4.26, 10.2.8, 10.5.1 |
| Confluence Data Center | 9.2.26, 10.2.19 |
| Jira Service Management Data Center | 5.12.40, 10.3.26, 11.3.12 |
| Jira Software Data Center | 9.12.40, 10.3.26, 11.3.12 |
| Bamboo Data Center | 10.2.24, 12.1.12 |
| Crowd Data Center | 6.3.7, 7.0.3, 7.1.7, 7.2.4 |
| Crucible | 4.9.15 |
| Fisheye | 4.9.15 |
Il s’agit des versions corrigées, et non d’une liste exhaustive des versions vulnérables. Les opérateurs doivent choisir une version corrigée adaptée à la branche qu’ils maintiennent.
Pour les systèmes qui ne peuvent pas être mis à jour immédiatement, les mesures temporaires préconisées par Atlassian comprennent le retrait des instances concernées de l’Internet public et l’application d’une règle de pare-feu applicatif (WAF). BleepingComputer a également indiqué qu’un WAF ou un proxy pouvait bloquer les schémas de traversée spécifiés pour les huit familles de produits concernées, y compris Crucible et Fisheye.
Les mesures propres à chaque produit comprennent :
RewriteValvede Tomcat pour Confluence, Jira Service Management, Jira Software, Bamboo et Crowd- Une règle dans
urlrewrite.xmlpour Bitbucket
Les articles ne reproduisent pas les règles précises à appliquer au WAF, au proxy, à RewriteValve ou à urlrewrite.xml. watchTowr a également publié un scanner gratuit permettant de vérifier si une instance est vulnérable, mais l’adresse de cet outil ne figurait pas dans les éléments disponibles.
La mesure durable consiste à installer une version corrigée. Les restrictions réseau et le filtrage des requêtes permettent de réduire l’exposition pendant la mise à jour.
