Faille critique Jira, Confluence ou Bitbucket Data Center : la marche à suivre pour protéger votre serveur

Quand une faille critique Jira, Confluence ou Bitbucket Data Center est annoncée, la bonne réaction tient en trois gestes, dans cet ordre : couper l’accès du serveur depuis Internet, installer la version corrigée indiquée par Atlassian, puis fouiller les journaux pour savoir si quelqu’un est passé avant vous. Le correctif ferme la porte. Il ne dit rien de ce qui s’est produit pendant qu’elle était ouverte.

Ce guide prend comme cas d’application la CVE-2026-21589, une vulnérabilité notée 9,3 sur 10 qui touche toute la gamme auto-hébergée de l’éditeur. La méthode reste la même pour les alertes du même type, et il y en a régulièrement.

En bref : la solution rapide

• Vérifiez votre édition. Les offres Cloud sont corrigées par Atlassian sans intervention de votre part. Les installations Data Center, celles que vous hébergez vous-même, sont à traiter.
• Retirez le serveur d’Internet tout de suite : accès limité au réseau interne ou au VPN, y compris si une page de connexion protège déjà l’instance.
• Prenez un instantané de la machine et une sauvegarde de la base, puis passez à la version corrigée de votre branche.
• Si la mise à niveau doit attendre, posez la règle de blocage temporaire publiée par Atlassian.
• Examinez les journaux d’accès et, au moindre doute, renouvelez tous les secrets stockés sur le serveur.

Reconnaître le problème

Rien ne s’affiche à l’écran. C’est le premier piège de ce genre de faille : Jira répond normalement, les tickets s’ouvrent, Confluence affiche ses pages. Aucune bannière rouge, aucun ralentissement. Vous l’apprenez par un courriel d’Atlassian, un avis du CERT-FR, un collègue, ou votre scanner de vulnérabilités qui passe au rouge.

Vous êtes concerné si vous cochez les deux cases suivantes.

Première case, l’édition. La CVE-2026-21589 vise les produits Data Center : Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, ainsi que Fisheye et Crucible. Atlassian indique que toutes les versions sont touchées, y compris celles qui ne sont plus maintenues. Si l’adresse de votre Jira se termine par atlassian.net, vous êtes sur le Cloud : l’éditeur a déjà corrigé sa plateforme et déclare n’y avoir trouvé aucune trace d’exploitation.

Seconde case, la version. Elle se lit dans l’administration de chaque produit, sur la page d’informations système, et le plus souvent en pied de page de l’interface. Dans Jira, cette même page d’informations système contient une rubrique des chemins de fichiers qui vous servira plus loin pour retrouver les journaux. Notez le numéro complet à trois chiffres, par exemple 10.3.25 : c’est le dernier qui compte.

Le cas des anciennes éditions Server mérite une ligne à part. Elles ne reçoivent plus de correctifs de sécurité. L’avis d’Atlassian ne les cite pas, mais la fiche CVE les range parmi les versions touchées sans correctif disponible, selon la lecture qu’en fait The Hacker News. Considérez une instance Server comme vulnérable et non réparable.

Pourquoi cela se produit

La CVE-2026-21589 est une faille d’accès arbitraire aux fichiers. En clair : une personne non connectée, sans compte, peut demander au serveur de lui remettre certains fichiers rangés dans le répertoire racine de l’application web, alors qu’ils ne devraient jamais sortir. La faille relève de la catégorie CWE-552, celle des fichiers accessibles à des tiers.

Atlassian apporte deux nuances. L’attaquant doit connaître à l’avance le nom et le chemin exacts du fichier visé, et il ne peut pas lister le contenu des dossiers. Cela limite la casse, sans rassurer pour autant : l’arborescence d’un produit Atlassian est publique, identique d’une installation à l’autre, et documentée. L’éditeur reconnaît d’ailleurs que certaines configurations contiennent des fichiers sensibles qui aggravent le risque.

La note de 9,3 en CVSS 4.0 tient aux dégâts en cascade. Un fichier de configuration lu, c’est parfois un mot de passe de base de données ou un jeton d’API, donc une porte vers autre chose.

Avant de commencer

Ouvrez un fichier texte et notez l’heure de chaque action. En cas d’incident avéré, cette chronologie vous sera réclamée par votre direction, votre assureur ou l’autorité de protection des données.

Ne supprimez rien. Ni journaux, ni fichiers suspects, ni comptes bizarres. Un nettoyage précipité efface les preuves.

Solution 1 : isoler le serveur d’Internet

C’est le geste de la première heure, et il ne casse rien. Atlassian demande de restreindre l’accès externe aux instances joignables depuis Internet, y compris celles qui exigent une authentification. La précision compte : la faille s’exploite sans compte, la page de connexion ne protège donc de rien.

1. Fermer l’accès public

Sur le pare-feu de périmètre ou le groupe de sécurité de votre hébergeur, limitez les ports web de l’instance aux adresses de votre réseau interne et de votre VPN. Si un reverse proxy Nginx sert l’application, deux directives suffisent dans le bloc concerné, à adapter à votre plage d’adresses :

allow 10.8.0.0/24;
deny all;

Prévenez les utilisateurs : les collaborateurs en télétravail passeront par le VPN, et les clients d’un portail Jira Service Management public perdront l’accès le temps de l’intervention.

2. Vérifier

Testez l’adresse publique depuis une connexion extérieure, un téléphone en 4G par exemple. Vous devez obtenir un refus ou un délai dépassé, pas la page de connexion.

L’isolement fait gagner du temps. Il ne dispense pas du correctif, car un poste interne compromis atteint toujours le serveur.

Solution 2 : sauvegarder, puis installer la version corrigée

C’est la seule réparation réelle. Atlassian ne publie plus de correctifs binaires à appliquer par-dessus une installation : la correction passe par une version de maintenance complète.

1. Figer l’état de la machine

Prenez un instantané de la machine virtuelle et une sauvegarde de la base de données. Ce double sert de retour arrière et de pièce à conserver si une enquête devient nécessaire.

2. Choisir la bonne version

Restez dans votre branche et prenez la version de maintenance corrigée. Pour la CVE-2026-21589, l’avis officiel donne les versions suivantes. Contrôlez-les sur la page d’Atlassian avant de télécharger, car l’éditeur met parfois ses avis à jour.

Si votre branche ne figure pas dans la liste, elle n’est plus maintenue : il faut monter vers une branche qui l’est, ce qui représente un chantier plus long. Dans ce cas, appliquez la solution 3 en attendant.

3. Tester, puis mettre à niveau

Si vous disposez d’une préproduction, passez-la en premier et vérifiez les extensions tierces, qui sont la cause habituelle des mises à niveau ratées. Sinon, l’instantané fait office de filet. En cluster, traitez tous les nœuds. Pour Bitbucket, Atlassian précise que les miroirs sont aussi concernés.

4. Vérifier

Relisez le numéro de version dans l’administration, ouvrez un ticket ou une page de test, contrôlez que les extensions sont actives. Ne rouvrez l’accès extérieur qu’après la solution 4.

Solution 3 : poser une atténuation temporaire si la mise à niveau doit attendre

Atlassian propose des règles de blocage et les qualifie lui-même de limitées : elles ne remplacent pas le correctif. Elles servent à tenir quelques jours, le temps d’obtenir une fenêtre de maintenance.

Le principe est de refuser les requêtes dont l’adresse contient deux points consécutifs collés à un séparateur de chemin, sous toutes leurs formes encodées. L’expression exacte est longue et se recopie mal. Prenez-la sur l’avis officiel, par copier-coller, sans la retaper.

Trois endroits où la poser, selon le produit :

• Sur le WAF ou le reverse proxy, pour tous les produits. C’est la seule option pour Fisheye et Crucible.
• Dans Tomcat, pour Jira, Jira Service Management, Confluence, Bamboo et Crowd : activation du composant RewriteValve dans le fichier server.xml, puis ajout d’un fichier rewrite.config dans le dossier WEB-INF, sur chaque nœud, suivi d’un redémarrage.
• Dans Bitbucket : une règle placée en tête du fichier urlrewrite.xml, dans le dossier app/WEB-INF du répertoire d’installation, puis redémarrage.

Sauvegardez les fichiers avant de les modifier : une erreur de syntaxe dans server.xml empêche l’application de démarrer.

Solution 4 : rechercher des traces de compromission

Atlassian écrit qu’il ne peut pas confirmer si vos instances ont été touchées. La vérification vous revient.

1. Les journaux d’accès

L’indicateur donné par l’éditeur est simple à énoncer : dans les journaux d’accès HTTP, cherchez les requêtes contenant deux points consécutifs accolés à une barre oblique, une barre oblique inversée ou un double deux-points. Les attaquants encodent souvent ces caractères, d’où la consigne de décoder les adresses jusqu’à deux fois avant de chercher, ou d’appliquer directement l’expression de blocage aux lignes brutes.

Regardez aussi les journaux du reverse proxy et du WAF, souvent conservés plus longtemps que ceux de l’application.

Lisez ensuite le code de réponse. Une requête suspecte suivie d’un code 200 et d’un volume de données non nul mérite une vraie inquiétude. Un code 404 signale plutôt une tentative ratée. L’avis ne détaille pas cette distinction : c’est une lecture de bon sens, pas une garantie.

2. Ce qu’un fichier volé permet ensuite

Une lecture de fichier ne modifie rien sur le serveur. Le danger vient de ce que l’attaquant fait avec un secret récupéré. Contrôlez donc les suites possibles :

• les comptes administrateurs créés ou promus sans raison connue ;
• les extensions installées que personne n’a demandées ;
• les jetons d’API et les liens d’application apparus hors de vos opérations ;
• les tâches planifiées du système et les services inconnus ;
• les connexions sortantes du serveur vers des adresses inhabituelles ;
• les connexions à la base de données depuis une autre machine que le serveur applicatif.

Dans Jira, le fichier atlassian-jira-security.log, rangé dans le sous-dossier log du répertoire de données, consigne les connexions et les refus d’accès. Le journal d’audit de chaque produit retrace les changements d’administration.

Solution 5 : réagir si vous trouvez des traces

Maintenez le serveur isolé et conservez tout : l’instantané pris plus tôt, une copie des journaux hors de la machine, la chronologie de vos actions.

Renouvelez ensuite les secrets, en partant du principe que tout ce qui figurait dans un fichier a pu être lu. Mot de passe du compte de base de données, compte de liaison à l’annuaire LDAP ou Active Directory, identifiants du serveur de messagerie, jetons d’API personnels, liens d’application, clés SSH et jetons d’accès Bitbucket, certificats privés si leur clé était stockée dans l’arborescence. L’avis d’Atlassian ne donne pas de consigne sur ce point ; c’est pourtant la suite logique d’une faille de lecture de fichiers.

Si des modifications ont été faites par un tiers, corrigez d’abord, restaurez ensuite. Une sauvegarde antérieure à l’intrusion remise en ligne sur une version vulnérable se fait reprendre dans la journée.

Reste le volet légal. Jira et Confluence contiennent presque toujours des données personnelles : noms, adresses électroniques, tickets de clients, parfois des dossiers de ressources humaines. Si la violation présente un risque pour les personnes, le responsable de traitement doit la notifier à la CNIL dans les 72 heures suivant sa découverte. La CNIL accepte une notification en deux temps : une déclaration initiale dans le délai, puis un complément une fois l’enquête terminée. Les personnes concernées doivent être prévenues directement quand le risque est élevé. Hors de France, adressez-vous à l’autorité de protection des données de votre pays.

Tableau récapitulatif

Si rien ne fonctionne

La mise à niveau échoue : restaurez l’instantané, laissez le serveur isolé, posez l’atténuation, puis ouvrez un ticket au support Atlassian. Joignez-y le produit, la version de départ, la version visée, la base de données utilisée, le journal de démarrage et la liste des extensions. Un ticket complet est traité bien plus vite.

Vous soupçonnez une intrusion sans avoir les moyens de l’analyser : appelez un prestataire de réponse à incident. En France, la plateforme Cybermalveillance.gouv.fr oriente les petites structures vers des prestataires référencés. Si vous avez une assurance cyber, déclarez l’incident avant toute intervention lourde, certains contrats l’exigent.

Éviter que cela se reproduise

La mesure la plus rentable est aussi la plus simple : ne plus exposer ces outils directement. Un Jira interne n’a pas besoin de répondre au monde entier. Placez-le derrière un VPN ou une passerelle d’accès Zero Trust, qui vérifie l’identité et l’appareil avant de laisser passer la moindre requête. Si un portail client doit rester public, isolez-le derrière un WAF et rangez le serveur dans une zone réseau séparée du reste.

Suivez les alertes à la source. Atlassian publie ses avis critiques pour les produits Data Center le mardi, et un bulletin mensuel le troisième mardi de chaque mois. Ajoutez les avis du CERT-FR et bloquez un créneau de maintenance dans la foulée. Rester sur une version de support à long terme facilite les choses : l’éditeur y reporte les corrections critiques.

Enfin, regardez l’horizon. Les éditions Server ne sont plus corrigées, et Atlassian a annoncé la fin programmée de l’offre Data Center pour Jira, Confluence et Crowd, avec maintien des corrections critiques jusqu’à l’échéance. Bitbucket et Bamboo ne suivent pas ce calendrier. Chaque alerte de ce type est une occasion de chiffrer une migration.

Questions fréquentes

Jira Cloud et Confluence Cloud sont-ils concernés par cette faille ?

Atlassian a corrigé sa plateforme Cloud et n’y a pas trouvé de trace d’exploitation. Aucune action n’est demandée aux clients Cloud.

Mon serveur n’est joignable qu’en interne, dois-je quand même corriger ?

Oui. La version reste vulnérable, seul le nombre d’attaquants possibles diminue. Un poste infecté ou un prestataire connecté au VPN suffit. L’urgence est moindre, pas l’obligation.

La page de connexion ne suffit-elle pas à me protéger ?

Non. La faille s’exploite sans authentification. Atlassian vise explicitement les instances publiques dotées d’une authentification dans sa consigne d’isolement.

Faut-il vraiment changer tous les mots de passe si je ne trouve aucune trace ?

Si vos journaux couvrent toute la période d’exposition et sont propres, ce n’est pas indispensable. S’ils sont incomplets ou trop courts, renouvelez au minimum le mot de passe de la base, le compte d’annuaire et les jetons d’API.

Mon édition Server n’a pas de correctif, que faire ?

La retirer d’Internet définitivement, la laisser accessible par VPN uniquement, et planifier la migration. Aucune règle de filtrage ne compense durablement l’absence de mises à jour.

Une faille critique Jira, Confluence ou Bitbucket Data Center se traite mieux avec une procédure écrite à l’avance qu’avec de bons réflexes improvisés. Si vous avez rencontré un blocage pendant la mise à niveau ou trouvé une méthode de contrôle des journaux qui vous a fait gagner du temps, racontez-le en commentaire : d’autres administrateurs en profiteront.