Une authentification à l’entrée ne bloque pas CVE-2026-21589 sur les produits Atlassian auto-hébergés

Atlassian a signalé le 5 octobre 2026 une vulnérabilité critique permettant de lire certains fichiers sur plusieurs produits Data Center auto-hébergés.

Un accès sans compte, à condition de connaître le fichier

Répertoriée sous l’identifiant CVE-2026-21589, la faille concerne l’accès aux fichiers placés dans le répertoire racine web de l’application vulnérable. Un attaquant peut tenter de récupérer un fichier précis sans disposer d’un compte et sans passer par l’authentification habituelle. La protection de la page de connexion ne constitue donc pas, à elle seule, une barrière contre ce comportement.

La portée de la vulnérabilité reste toutefois délimitée. L’attaquant doit déjà connaître le nom exact du fichier recherché et son chemin complet. CVE-2026-21589 ne lui fournit aucun moyen de parcourir les dossiers, d’en afficher le contenu ou de découvrir automatiquement les fichiers disponibles. Elle ne démontre pas non plus un accès général au système de fichiers du serveur, une modification des données ou une exécution de code à distance.

Cette contrainte réduit les possibilités de recherche à l’aveugle, mais elle ne supprime pas le risque pour les fichiers dont l’emplacement peut être connu ou deviné par d’autres moyens. Selon Cybersecurity News, les versions non corrigées des produits concernés doivent être mises à niveau sans délai. CyberPress précise que cette priorité concerne aussi les déploiements exposés à Internet alors que leur usage normal exige une authentification.

Les versions Data Center à contrôler

Le contrôle doit porter sur les déploiements auto-hébergés de Jira Software Data Center, Jira Service Management Data Center, Confluence Data Center et Bitbucket Data Center. Pour chacun, les versions antérieures aux éditions correctives correspondant à leur branche sont concernées.

Une organisation doit d’abord inventorier chaque instance et relever le produit, la branche et la version réellement exécutée. Le numéro le plus élevé du tableau n’est pas nécessairement la seule destination possible, puisque plusieurs branches disposent de leur propre version corrigée. Il faut sélectionner celle qui correspond au cycle de maintenance de l’installation, puis vérifier que la mise à niveau a bien été appliquée à tous les composants du déploiement.

Dans un environnement Data Center réparti, le contrôle ne peut pas se limiter à l’adresse publique ou à un seul serveur. Chaque nœud concerné doit exécuter une version corrigée. La présence simultanée de plusieurs produits Atlassian impose également une vérification séparée de chacun d’eux, car la mise à jour de Confluence ne protège pas une instance Jira ou Bitbucket distincte.

Correctif d’abord, réduction de l’exposition si nécessaire

Atlassian recommande d’installer immédiatement une version corrigée. Si cette opération exige une validation préalable, une fenêtre de maintenance ou une adaptation incompatible avec une intervention immédiate, la réduction de l’exposition externe devient la mesure prioritaire pendant cet intervalle.

1. Recenser les instances auto-hébergées, y compris celles qui ne sont pas directement utilisées par le public mais restent accessibles depuis Internet.
2. Comparer leur version avec la première édition corrigée de la branche correspondante.
3. Installer la mise à jour de sécurité sur toutes les instances et tous les nœuds concernés.
4. À défaut de correctif immédiat, retirer l’instance d’Internet ou limiter strictement son accès réseau externe. Cette précaution reste nécessaire même si une connexion utilisateur protège normalement l’application.

L’ordre des opérations compte. Une règle d’authentification, un portail de connexion ou un contrôle d’accès propre à l’application ne répond pas au scénario décrit, puisque la requête malveillante peut provenir d’un utilisateur non connecté. La restriction doit donc intervenir au niveau de l’exposition réseau, en amont de l’application vulnérable.

Une mitigation temporaire à déployer sur chaque nœud

Lorsqu’une mise à jour ne peut pas être installée immédiatement, une organisation peut filtrer les motifs de traversée de chemin indiqués par Atlassian à l’aide d’un pare-feu applicatif web ou d’un proxy. Selon le produit, une configuration Tomcat RewriteValve peut également servir de mesure provisoire. Ces règles doivent être testées avant leur généralisation afin de confirmer que le dispositif de filtrage interprète correctement les motifs attendus et n’interrompt pas des usages légitimes.

Dans un cluster, la mitigation doit couvrir chaque nœud vulnérable. Une règle active uniquement sur un frontal, un serveur ou une partie du déploiement peut laisser subsister un autre chemin d’accès. Les équipes doivent aussi conserver une configuration cohérente pendant toute intervention de maintenance, notamment si le trafic est redistribué entre plusieurs nœuds.

Le filtrage reste une mesure d’attente et non un remplacement du correctif. Une fois la protection provisoire en place, la mise à niveau vers l’une des versions corrigées demeure nécessaire pour traiter CVE-2026-21589 dans le produit lui-même.

Photo à la une. Source : Wikimedia Commons. Photographe : Alexis Lê-Quôc from New York, United States. Licence : CC BY-SA 2.0.