Ah, Atlassian… cette douce symphonie de tickets, de sprints et de workflows Jira qui s’allongent plus vite qu’un tunnel VPN mal configuré. Aujourd’hui, on parle de CVE-2025-22167, une faille toute neuve dans Jira Server et Data Center, notée 8.7 sur l’échelle du “ça va mal finir”.
Spoiler : si ton Jira tourne On-Premise, tu es potentiellement concerné. Si tu es sur Jira Cloud, respire : pour une fois, ce n’est pas toi le dindon de la farce.

🧩 Contexte — Cloud vs On-Premise : qui doit paniquer ?

Commençons par le plus simple.

• Jira Cloud (Atlassian-hosted) : pas concerné. Atlassian a déjà patché ses propres serveurs. Les équipes Cloud peuvent donc ranger les extincteurs et continuer à se battre avec leurs backlog grooming.
• Jira Server / Data Center (On-Premise) : vulnérables. Et là, on parle de plus de 100 000 instances exposées sur Internet selon les scans ZoomEye et Shodan. Oui, certaines de ces instances sont directement accessibles sans WAF, ni MFA. On adore ce niveau de confiance dans la nature humaine.

En résumé :

🌩️ Cloud : tu dors tranquille.
🏚️ On-Premise : tu vérifies tes logs avant d’aller dormir.

🧠 Ce qu’il se passe (techniquement, mais sans migraine)

La faille est un Path Traversal dans Jira Server / Data Center.
En gros, un utilisateur (authentifié ou non selon le contexte) peut écrire des fichiers arbitraires n’importe où sur le système, tant que le répertoire est accessible en écriture par la JVM.

Tu veux écrire un fichier dans /opt/atlassian/jira/lib/ ? Facile.
Tu veux injecter un script dans un répertoire temporaire exécuté par Tomcat ? Tout aussi facile.
Tu veux t’amuser avec un .jsp qui se lance à la volée ? Jackpot.

Et là où ça devient croustillant, c’est que cette faille peut être combinée avec d’autres exploits pour obtenir une exécution de code à distance (RCE). En clair : on part d’un petit “je dépose un fichier” pour finir sur un “coucou, je contrôle ton serveur”.

🔥 Risques concrets — et un peu d’ironie salvatrice

Soyons clairs : ce n’est pas une “petite faille gênante”.

• 🧨 Écriture arbitraire = porte ouverte à toutes les manipulations.
• 👾 Possibilité de RCE si l’attaquant sait où écrire (ce qui, entre nous, n’est pas bien compliqué).
• 📦 Altération de fichiers système ou applicatifs (scripts, configs, plugins, etc.).
• 🕵️ Persistance discrète : un attaquant peut planquer un webshell bien au chaud et revenir plus tard, comme un stagiaire oublié à la machine à café.
• 🔗 Chaînage possible avec d’autres CVE Jira publiées ces derniers mois.

Et cerise sur le ticket, Atlassian a noté que la faille touche aussi Jira Service Management. Donc si tu gères ton helpdesk interne avec Jira, félicitations : ton outil de support est potentiellement la nouvelle porte d’entrée du SI.

🧯 Ce qu’il faut faire (tout de suite, pas demain)

Allez, on retrousse les manches.

1️⃣ Identifier les versions concernées

La faille impacte les versions 9.12.0 à 11.0.1 de Jira Server et Data Center.
Atlassian a publié les correctifs dans les versions 9.12.4, 9.13.2 et 11.0.2 (vérifie dans le bulletin officiel).

2️⃣ Patch, patch, patch

C’est la solution officielle, testée et approuvée par tous les admins fatigués.
Mets à jour, vérifie les plugins, et redémarre proprement. Oui, ça prendra du temps. Oui, ça fera râler les utilisateurs. Mais entre un Jira indisponible 30 minutes et un Jira transformé en botnet russe, le choix est vite fait.

3️⃣ Restreindre l’accès

En attendant le patch :

• Bloque les accès directs depuis Internet.
• Passe par un VPN, un reverse proxy, ou mieux : un WAF avec une règle anti-traversal.
• Vérifie les permissions du processus Jira (le compte système ne doit pas pouvoir écrire partout).

4️⃣ Auditer les logs et les fichiers

Cherche des traces d’activité suspecte :

• Fichiers créés récemment sous /var/atlassian/, /tmp/, /lib/, etc.
• Requêtes HTTP contenant ../ ou %2e%2e.
• Toute modification de fichiers .jsp, .jar, .class non prévue.

5️⃣ Documenter et sensibiliser

Fais un petit RETEX interne. Non, pas pour pointer du doigt l’équipe Jira — elle souffre déjà assez.
Mais pour montrer à la DSI que l’exposition des instances internes sur Internet “pour la praticité” a un coût. Et que le patch management, ce n’est pas une option.

💬 Pour finir — un peu de compassion (et d’humour)

Les équipes qui gèrent Jira ne méritaient pas ça.
Elles jonglent déjà entre les sprints, les tickets oubliés et les demandes de “juste un petit changement dans le workflow”. Alors quand Atlassian leur balance une faille notée 8.7, c’est un peu comme si on rajoutait du gravier dans le café du matin.

Mais rappelons-le :
👉 Cette faille ne touche que les versions On-Premise (donc les entreprises qui veulent garder la main… sur leurs problèmes).
👉 Les patchs sont disponibles.
👉 Et avec un peu de rigueur (et un café très fort), tout ça se corrige vite.

🧰 TL;DR — La check rapide

💡 Conseils SecuSlice

🧱 1. Ne laisse jamais un outil critique exposé sans filtre réseau.
Un reverse proxy, un WAF ou même un simple filtrage IP peuvent sauver ta nuit. Le SaaS a ses défauts, mais l’exposition publique d’un serveur vulnérable, c’est encore pire.

🧩 2. Automatise le patch management.
Un Jira oublié, c’est une bombe à retardement. Mets en place des alertes ou un pipeline Ansible pour tes patchs — surtout sur les outils Atlassian.

🕵️ 3. Surveille tes logs comme un parano lucide.
Une fois par semaine, scanne tes journaux applicatifs et système. Pas besoin d’un SIEM hors de prix : un simple grep -R "../" vaut parfois un million.

💬 Parce qu’en cybersécurité, l’humour ne protège pas les serveurs… mais il aide à encaisser les CVE du lundi matin.

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com