Des attaquants ont commencé à exploiter une vulnérabilité critique dans les produits Atlassian quelques heures après la publication d’un rapport technique détaillé et d’un outil public de preuve de concept. La vulnérabilité, identifiée sous le numéro CVE-2026-21589, ne nécessite aucune authentification et affecte les instances Data Center auto-hébergées de Jira, Confluence, Bitbucket et d’autres produits.
Que permet la vulnérabilité ?
Le problème permet à un attaquant d’accéder à certains fichiers situés dans la racine web de l’application s’il connaît précisément le nom et le chemin du fichier. La faille est liée à une bibliothèque partagée de traitement des ressources web, qui transforme la chaîne :: en barres obliques, ce qui permet de construire des requêtes incluant une traversée de répertoires via les points d’accès des ressources des modules complémentaires et de lire des fichiers protégés sans se connecter.
Les chercheurs de watchTowr ont confirmé la lecture de fichiers dans Jira, Confluence et Bitbucket, mais leur méthode n’a pas permis de sortir du périmètre de l’application Tomcat ni d’accéder à des fichiers situés en dehors de celui-ci.
Produits concernés
- Bitbucket Data Center
- Confluence Data Center
- Jira Service Management Data Center
- Jira Software Data Center
- Bamboo Data Center
- Crowd Data Center
- Crucible
- Fisheye
Un risque supplémentaire dans les environnements connectés à Crowd
Dans certains déploiements de Jira intégrés à Atlassian Crowd, les fichiers lus peuvent être utilisés pour accéder à des identifiants en clair dans le fichier WEB-INF/classes/crowd.properties. Si Crowd est accessible depuis le réseau et que l’application dispose des autorisations nécessaires, ces données peuvent permettre de créer un compte administrateur dans Jira via l’interface de programmation de Crowd, puis de créer des utilisateurs et de modifier les autorisations dans le système de gestion des identités.
L’exploitation devient plus difficile si les adresses IP autorisées à accéder à Crowd sont limitées, car l’attaquant peut devoir passer par d’autres appareils ou utiliser des capacités similaires à des requêtes SSRF pour y accéder directement. Ces conditions signifient que l’impact de la vulnérabilité varie selon l’architecture du déploiement et les autorisations, mais qu’il peut dépasser la simple lecture de fichiers dans les environnements non protégés.
Pourquoi cette information est-elle importante ?
La société Previdian a détecté des tentatives d’exploitation sur son réseau honeypot dans les deux heures suivant la publication de l’étude de watchTowr et de l’outil de preuve de concept. La publication d’un modèle Nuclei a également facilité l’analyse automatisée des systèmes vulnérables. Les tentatives observées provenaient notamment des adresses IP 38.60.157[.]86, 146.70.187[.]234 et 159.26.119[.]225, que la société recommande de bloquer.
La chronologie indique que la publication de détails exploitables a rapidement transformé la vulnérabilité, d’un problème signalé en une cible pour l’analyse et l’exploitation automatisées, tandis que le risque s’est accru en raison du nombre de produits Atlassian concernés. Previdian s’attend à une augmentation de l’activité au cours des prochains jours et des prochaines semaines.
Que doivent faire les responsables ?
Atlassian a recommandé d’appliquer les mises à jour de sécurité disponibles dans les meilleurs délais, tout en précisant qu’elle ne pouvait pas déterminer si les instances des clients avaient été compromises. Les mesures d’atténuation comprennent la restriction de l’accès externe, l’utilisation d’un pare-feu applicatif web ou d’une règle de proxy pour bloquer les schémas identifiés de traversée de répertoires, ainsi que des règles Tomcat RewriteValve pour les produits Confluence, Jira Service Management, Jira, Bamboo et Crowd, ou une règle de réécriture des URL dans Bitbucket.
watchTowr a également publié un outil d’analyse gratuit pour aider les responsables à vérifier si leurs instances sont exposées à la vulnérabilité. Les résultats de l’analyse ainsi que l’audit des comptes et des autorisations restent particulièrement importants pour les environnements utilisant Crowd, car la source établit la possibilité d’un accès administrateur uniquement dans certains scénarios, et non dans tous les déploiements.