Atlassian CVE-2026-21589 : 8 produits lisibles sans login
Jira, Confluence, Bitbucket : ce que les PME auto-hébergées doivent faire cette semaine
Image générée par IA (art. 50 AI Act)
Analyse 2LKATIME
Atlassian a publié le 5 octobre 2026 un correctif pour une faille critique touchant huit produits Data Center. Nos auditeurs résument ce qu'il faut savoir, vérifier et appliquer, sans alarmisme.
Si vous hébergez Jira ou Confluence vous-même, c'est pour vous
Les clients du cloud Atlassian n'ont rien à faire. Les instances auto-hébergées exposées sur internet doivent être mises à jour ou isolées dès maintenant.
Atlassian a divulgué le 5 octobre 2026 la faille CVE-2026-21589, notée 9,3 sur 10. Elle permet à un attaquant sans compte de lire des fichiers situés dans le répertoire racine de l'application web, sur huit produits Data Center : Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible et Fisheye.
Le détail qui tempère le score : l'attaquant doit connaître le nom et le chemin exacts du fichier visé, et il ne peut pas afficher le contenu du répertoire. Le danger dépend donc de ce que votre serveur laisse dans cette racine. Dans certaines configurations, elle contient des fichiers sensibles, ce qui suffit à justifier un correctif rapide.
1. Ce que dit l'avis Atlassian
9,3
Score CVSS 4.0, évalué par Atlassian
8
Produits Data Center concernés
0
Authentification requise
0
Exploitation confirmée à ce jour
La faille est un path traversal : une requête construite avec un chemin spécial atteint des fichiers qu'elle ne devrait pas voir. Elle est joignable par le réseau, sans privilège ni action de l'utilisateur. L'impact sur la confidentialité est noté élevé, celui sur l'intégrité et la disponibilité nul. Atlassian précise que ce score est le sien et invite chaque client à juger de son effet dans son environnement.
Les produits cloud d'Atlassian concernés sont déjà corrigés, et Bitbucket Cloud n'est pas touché. L'éditeur dit n'avoir trouvé aucune preuve d'exploitation de ses services cloud, mais ajoute ne pas pouvoir confirmer si des instances auto-hébergées ont été atteintes. Il recommande aux clients qui ne peuvent pas mettre à jour tout de suite de retirer l'instance d'internet si possible, et de restreindre l'accès extérieur à toute instance joignable publiquement, même derrière un login.
Précédent utile : CVE-2021-26086, un path traversal de même nature dans Jira, a été exploité dans la nature et ajouté au catalogue des vulnérabilités exploitées de la CISA américaine le 12 novembre 2024. Attendre une exploitation confirmée avant d'agir n'est pas un pari prudent.
2. Les versions corrigées
Toutes les versions antérieures aux versions ci-dessous sont concernées, y compris celles en fin de vie. Atlassian recommande de passer à une version LTS corrigée ou plus récente.
| Produit | 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 Software Data Center | 9.12.40, 10.3.26, 11.3.12 |
| Jira Service Management Data Center | 5.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 |
Attention aux écarts dans la documentation. Selon The Hacker News, la fiche Crowd 7.1 indique 7.1.7 comme correctif alors qu'un tableau voisin cite 7.1.6, et l'enregistrement CVE donne pour Bamboo 10.2.4 dans un champ et 10.2.24 dans un autre. Ce même enregistrement liste aussi les éditions Server (Bamboo, Bitbucket, Confluence, Crowd) comme concernées, sans version corrigée. Pour vos montées de version, fiez-vous à l'avis officiel d'Atlassian et pas à un tableau recopié ailleurs.
3. Si vous ne pouvez pas mettre à jour aujourd'hui
Sortir l'instance d'internet
C'est la mesure la plus efficace. Si Jira ou Confluence ne sert qu'à vos équipes, placez-le derrière un VPN ou une liste d'adresses autorisées. Atlassian demande d'appliquer cette restriction même aux instances qui exigent une connexion.
Bloquer les chemins piégés au niveau du reverse proxy
Les trois règles temporaires d'Atlassian bloquent les URL contenant deux points consécutifs collés à une barre oblique, une barre oblique inverse ou deux deux-points, y compris encodés. La règle WAF ou reverse proxy fonctionne pour les huit produits. Les règles Tomcat et urlrewrite demandent un redémarrage de chaque nœud.
Ces mesures ne font que gagner du temps
Atlassian le dit lui-même : ces mesures sont limitées et ne remplacent pas la mise à jour. Planifiez le correctif dans la semaine.
Voici une règle nginx de principe, à adapter et à tester sur un environnement de recette avant la production. Elle illustre la logique d'Atlassian mais ne remplace pas la règle exacte publiée dans l'avis officiel pour votre produit.
if ($request_uri ~* "(\.\.(/|\\|::))|((/|\\|::)\.\.)|(%2e%2e)|(%252e)") {
return 403;
}La variable $request_uri contient l'URL telle que reçue, avant normalisation par nginx, ce qui évite de manquer une séquence encodée. Un blocage trop large peut gêner des requêtes légitimes : testez avant de généraliser.
4. Chercher des traces d'accès passées
Atlassian demande aux équipes de sécurité de fouiller les journaux d'accès. La méthode : décoder chaque ligne de requête (jusqu'à deux fois) et repérer deux points consécutifs collés à une barre oblique, une barre oblique inverse ou deux deux-points. Une recherche rapide sur un serveur nginx :
sudo zgrep -hiE '\.\.(/|\\|::)|(/|\\|::)\.\.|%2e%2e|%252e' /var/log/nginx/access.log*Ce filtre est volontairement large et ramènera des faux positifs, notamment les scanners automatiques. Il a une limite que l'avis d'Atlassian ne lève pas : il ne distingue pas une tentative échouée d'une requête qui a renvoyé un fichier. Regardez le code de réponse et la taille renvoyée de chaque ligne suspecte. Une réponse 200 avec un volume non nul mérite une enquête approfondie.
5. RGPD, NIS2 : le patch management est une obligation
Jira et Confluence contiennent souvent des données personnelles : noms, adresses électroniques, pièces jointes, parfois des identifiants collés dans une page de documentation. Si un fichier de configuration lu par un attaquant donne accès à ces données, on est face à une violation à notifier à la CNIL sous 72 heures à compter de sa découverte.
Pour les entités soumises à NIS2, la gestion des vulnérabilités fait partie des mesures de gestion des risques attendues. Une faille critique connue, corrigée par l'éditeur et laissée ouverte sur une instance exposée est difficile à défendre en cas de contrôle ou d'incident.
6. Ce que 2LKATIME recommande
Trois actions, dans cet ordre. Recensez d'abord vos instances Atlassian auto-hébergées et vérifiez lesquelles sont joignables depuis internet : c'est l'information qui décide de l'urgence. Appliquez ensuite le correctif de la bonne branche, ou isolez l'instance en attendant. Passez enfin vos journaux au crible sur la période récente, avec la recherche ci-dessus.
Nos audits cybersécurité commencent justement par cet inventaire des services exposés, que beaucoup d'entreprises découvrent incomplet. Pour les structures de Paris, de Lille ou de Nantes, un contrôle des outils collaboratifs auto-hébergés se fait en une demi-journée.
FAQ - CVE-2026-21589 Atlassian
Mon Jira ou Confluence cloud est-il concerné par CVE-2026-21589 ?
Non. Atlassian indique que ses produits cloud concernés sont déjà corrigés et que Bitbucket Cloud n'est pas touché. Seuls les clients qui hébergent eux-mêmes les produits Data Center doivent agir.
Un attaquant peut-il lister les fichiers de mon serveur avec cette faille ?
Non. L'attaquant doit connaître le nom et le chemin exacts du fichier visé et ne peut pas afficher le contenu du répertoire. Le risque dépend donc de ce qui se trouve dans la racine de l'application.
Cette faille est-elle déjà exploitée ?
Atlassian n'a pas trouvé de preuve d'exploitation sur ses produits cloud, mais précise ne pas pouvoir confirmer si des instances auto-hébergées ont été touchées. Une faille du même type, CVE-2021-26086, a été exploitée dans la nature.
Que faire si je ne peux pas mettre à jour tout de suite ?
Retirer l'instance d'internet si possible, sinon restreindre l'accès depuis l'extérieur et appliquer une règle de blocage sur le pare-feu applicatif ou le reverse proxy. Ces mesures sont limitées et ne remplacent pas le correctif.
Comment savoir si quelqu'un a déjà tenté d'exploiter la faille ?
Rechercher dans les journaux d'accès des requêtes contenant deux points consécutifs collés à une barre oblique, une barre oblique inverse ou deux deux-points, y compris sous forme encodée. Atlassian ne précise pas comment distinguer une tentative échouée d'une lecture réussie.
Vos outils collaboratifs sont-ils exposés sur internet ?
2LKATIME recense vos services exposés, vérifie leur niveau de correctif et identifie ce qu'un attaquant verrait en premier.