Atlassian a publié des correctifs de sécurité pour Jira, Confluence et d’autres produits d’entreprise, corrigeant 176 vulnérabilités dans ses logiciels.
Publié le 20 octobre, le bulletin récapitule les correctifs publiés au cours du mois précédent pour plusieurs produits autogérés. Certains composants tiers concernés présentent un niveau de gravité critique, mais Atlassian évalue leur risque au sein de ses applications comme non critique. Les organisations qui utilisent des versions concernées doivent vérifier quelles installations nécessitent encore une mise à jour.
Certaines des découvertes les plus graves concernent des composants logiciels qui contribuent à empêcher les connexions non autorisées aux systèmes d’entreprise.
Des failles de sécurité affectent l’accès aux serveurs et la vérification des certificats
Plusieurs des problèmes présentant les niveaux de gravité les plus élevés concernent des bibliothèques logicielles tierces utilisées pour gérer les connexions sécurisées. Le bulletin de sécurité d’Atlassian recense trois vulnérabilités notables, avec les scores suivants indiqués dans son bulletin :
- CVE-2026-65637 (9,8) dans Apache Tomcat. Touchant Confluence et Crowd, cette faille peut contourner la validation stricte de l’indication du nom du serveur (SNI) pour certaines requêtes HTTP/2.
- CVE-2026-58062 (9,3) dans Bouncy Castle. Une validation défectueuse des certificats peut entraîner l’acceptation comme valide d’un certificat révoqué lorsque le composant reçoit une réponse d’état du certificat non concordante. Atlassian indique que Jira Software, Jira Service Management, Confluence et Crowd sont concernés.
- CVE-2026-75595 (9,1) dans Netty. Le composant réseau peut permettre à des attaquants de contourner l’authentification par certificat client lorsque l’authentification dépend entièrement d’une configuration fondée sur SNI, que la configuration de secours autorise les connexions sans certificat et que l’application n’effectue aucune vérification supplémentaire du certificat.
Les autres entrées concernent des failles d’exécution de code à distance et de déni de service. Sur l’ensemble, 162 présentent un niveau de gravité élevé et 14 concernent des composants tiers classés comme critiques, certains CVE étant répertoriés pour plusieurs produits.
Atlassian considère que leur impact au sein de ses applications est non critique, malgré les scores de gravité plus élevés de ces composants.
Des versions corrigées sont disponibles pour les produits Data Center pris en charge
Les mises à jour recommandées varient selon le produit et la branche de version. Le bulletin du 20 octobre recommande les versions suivantes ; les administrateurs doivent consulter les notes de version actuelles et vérifier les exigences de mise à niveau avant le déploiement :
Produit | Version corrigée recommandée |
| Jira Software Data Center | 11.3.12 LTS |
| Jira Service Management Data Center | 11.3.12 LTS |
| Confluence Data Center | 10.2.19 LTS |
| Bitbucket Data Center | 10.2.8 LTS |
| Bamboo Data Center | 12.1.12 LTS |
| Crowd Data Center | 7.2.4 |
| Fisheye and Crucible | 4.9.15 |
Pour les installations utilisant d’autres branches de version, le portail de signalement des vulnérabilités d’Atlassian répertorie les versions concernées et les correctifs disponibles.
Les anciennes éditions Server posent un problème différent. Jira, Confluence et la plupart des autres produits Server ne reçoivent plus de correctifs de sécurité depuis février 2024, laissant ces installations sans correctifs pris en charge. Fisheye et Crucible restent pris en charge jusqu’en mai 2028.
Une seule installation oubliée peut laisser une faille de sécurité non corrigée
Jira contient souvent les tickets utilisés pour attribuer et clôturer les tâches de sécurité, tandis que Jira Service Management prend en charge la gestion des incidents informatiques et que Confluence stocke les procédures internes de réponse.
Des équipes différentes peuvent administrer ces applications, même lorsqu’elles contiennent le même composant logiciel vulnérable. Un ticket de sécurité Jira clôturé peut donc donner aux administrateurs une vision incomplète si une installation concernée de Confluence ou de Crowd utilise encore une ancienne version.
Les responsables de la sécurité doivent suivre séparément chaque installation concernée dans leurs registres de gestion des vulnérabilités. Un CVE commun doit être associé aux serveurs réellement exécutant des versions vulnérables, les responsables des produits concernés devant confirmer chaque mise à jour. Une bonne vérification des correctifs consiste à contrôler la version du logiciel exécutée après le déploiement avant de considérer le problème comme résolu. Pour les déploiements en cluster, vérifiez chaque nœud et consignez le résultat pour l’installation concernée.
Pour les installations Server non prises en charge, désignez un responsable et fixez une échéance pour migrer vers une plateforme prise en charge. Restreignez l’accès pendant la migration et consignez ces mesures comme une réduction temporaire du risque, et non comme un correctif achevé.
Un rapport de correctifs achevé n’offre qu’une assurance limitée si une ancienne installation utilisée pour des tâches informatiques essentielles reste vulnérable et ne bénéficie plus du support de sécurité habituel.
Autres actualités de cybersécurité : les administrateurs de GitLab font face àune autre mise à jour de sécurité urgente après que l’entreprise a révélé sa deuxième faille d’exécution de code à distance notée 10,0 ce mois-ci.