Atlassian corrige une faille critique d’accès arbitraire aux fichiers qui touche sept produits Data Center
Le 6 octobre 2026, Atlassian a publié CVE-2026-21589, une faille critique qui laisse un attaquant non authentifié lire des fichiers précis dans la racine web de Confluence, Jira, Bitbucket et quatre autres produits Data Center self-hosted. Les instances Cloud sont déjà corrigées : seuls les administrateurs de Data Center doivent patcher ou poser les règles de mitigation, sur chaque nœud du cluster.
6 octobre 2026. Atlassian avertit ses clients d’une vulnérabilité critique, suivie sous le nom de CVE-2026-21589, qui permet un accès arbitraire aux fichiers dans plusieurs produits Data Center auto-hébergés, dont Confluence, Jira et Bitbucket. Non authentifié. L’attaquant n’a besoin d’aucune connexion. Sept produits. La faille touche huit références de produits au total, toutes des éditions self-hosted. Pourquoi c’est important : la faille se situe dans la couche de lecture de fichiers, et son exploitation exige de connaître le nom exact du fichier visé — un détail qui change la façon dont les équipes doivent chercher des traces.
Ce que la faille permet, et ce qu’elle ne permet pas
CVE-2026-21589 est décrite par Atlassian comme une vulnérabilité d’accès arbitraire aux fichiers (Arbitrary File Access). Elle permet à un attaquant non authentifié d’accéder à des fichiers précis situés dans le répertoire racine de l’application web concernée. La limite est explicite dans l’avis de sécurité : « l’exploitation nécessite la connaissance préalable du nom et du chemin exacts du fichier cible ; cette vulnérabilité ne permet pas d’énumérer ni de lister le contenu des répertoires ».
En clair, l’attaquant ne peut pas se promener dans l’arborescence et aspirer ce qu’il trouve. Il doit déjà savoir ce qu’il cherche — un nom de fichier de configuration, une sauvegarde, un fichier de clé — et où il se trouve. C’est une faille de lecture ciblée, pas de pillage en masse. Elle n’en reste pas moins critique : les fichiers qui vivent dans la racine web d’une instance Confluence, Jira ou Bitbucket peuvent contenir des secrets, des configurations ou des archives dont la seule lecture suffit à compromettre la suite.
Les produits et versions concernés
La faille touche toutes les versions publiées avant les versions corrigées listées ci-dessous. Les clients Cloud n’ont rien à faire : Atlassian a déjà patché leurs instances. Seuls les administrateurs d’instances Data Center auto-hébergées sont concernés.
| Produit (Data Center) | Versions corrigé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 |
La portée est large parce que ces produits partagent une plateforme commune. Un même correctif se décline donc en plusieurs numéros de version, un par branche de support encore maintenue. Les installations hors support — typiquement des Jira ou Confluence figés sur une ancienne majeure parce qu’un plugin ne suit plus — n’ont pas de correctif : elles devront s’appuyer sur les mitigations, ou migrer.
Patching, et les mitigations si le patch attend
Atlassian recommande d’appliquer les mises à jour immédiatement. Si le patch ne peut pas être posé tout de suite, l’éditeur demande de restreindre l’accès réseau externe, y compris pour les instances exposées qui exigent déjà une authentification. Trois familles de mitigations temporaires sont documentées dans l’avis : une règle de WAF ou de proxy qui bloque les motifs de traversée précis dans tous les produits concernés, des règles Tomcat RewriteValve pour Confluence, JSM, Jira, Bamboo et Crowd, et une règle de réécriture d’URL pour Bitbucket.
Un point d’attention revient dans l’avis et mérite d’être souligné : les changements doivent couvrir chaque nœud du cluster, y compris les miroirs Bitbucket et les nœuds de ferme de miroirs. Une mitigation posée sur le nœud principal mais pas sur un miroir laisse une porte ouverte. C’est l’erreur classique des architectures Data Center à plusieurs nœuds : on patch ce qu’on voit, on oublie ce qui réplique en arrière-plan.
Pas d’exploitation connue, mais des journaux à relire
Atlassian indique n’avoir aucune preuve que CVE-2026-21589 soit exploitée dans des attaques à ce jour. C’est une différence majeure avec les failles Atlassian précédentes — Confluence a longtemps été une cible de choix pour les ransomwares et les accès initiaux —, mais ce n’est pas un blanc-seing. L’éditeur recommande explicitement de relire les journaux d’accès à la recherche des motifs de traversée décrits dans le bulletin, et précise qu’il ne peut pas déterminer si telle ou telle instance cliente a été compromise. Chaque organisation qui gère du Data Center auto-hébergé doit donc faire sa propre analyse de journaux, en parallèle du patch.
La fenêtre compte. Ce type de faille, une fois public, est vite instrumentalisé : le délai entre une divulgation et les premières tentatives d’exploitation se mesure parfois en heures quand le produit est aussi répandu que Confluence ou Jira. Le fait que l’exploitation exige de connaître le nom du fichier ne découragera pas un attaquant qui a déjà des secrets à aller chercher.
Verdict
Si vous exploitez des instances Data Center auto-hébergées — Confluence, Jira, Bitbucket, Bamboo, Crowd, Crucible ou Fisheye — appliquez les versions corrigées immédiatement, puis relisez vos journaux à la recherche des motifs de traversée, sur tous les nœuds y compris les miroirs. Si vous êtes sur une version hors support sans correctif disponible, posez les règles WAF ou Tomcat RewriteValve documentées et planifiez la migration, car une mitigation réseau ne remplace pas un patch. Si vous êtes sur Cloud, vous n’avez rien à faire : l’instance est déjà corrigée par Atlassian. Le signal à retenir est moins la gravité que la géographie de la faille : elle ne frappe que le parc auto-hébergé, exactement celui qui ne reçoit pas de correctif automatique et qui, souvent, traîne des versions figées.