• Le délai du 14 septembre fixé par la CISA pour corriger la vulnérabilité GitLab CVE-2026-85706, activement exploitée, est dépassé
  • Le correctif de GitLab nécessite des migrations de base de données, ce qui met hors ligne les installations à nœud unique, tandis que les déploiements à plusieurs nœuds correctement mis à niveau peuvent éviter une interruption

Les faits

Le délai fixé par la CISA au 14 septembre pour corriger CVE-2026-85706 est dépassé. Cette vulnérabilité de GitLab, activement exploitée, peut permettre à un utilisateur non authentifié de lire des fichiers sur un serveur dans certaines conditions. La CISA a ajouté la faille à son catalogue Known Exploited Vulnerabilities le 11 septembre. Le délai fédéral s’applique aux agences civiles fédérales américaines assujetties à cette obligation.

GitLab a publié les versions corrigées 19.3.2, 19.2.6 et 19.1.8 le 10 septembre et a exhorté les clients concernés utilisant une installation autogérée à effectuer immédiatement la mise à niveau. GitLab.com a déjà reçu le correctif, tandis que les clients de GitLab Dedicated n’ont aucune mesure à prendre.

La mise à jour comprend des migrations de base de données. GitLab indique qu’une installation à nœud unique restera indisponible jusqu’à la fin de ces migrations. Les installations à plusieurs nœuds peuvent être mises à niveau sans interruption lorsque les opérateurs suivent la procédure de GitLab prévue à cet effet.

L’analyse

Pour une équipe qui exploite son propre serveur GitLab, la difficulté de ce correctif n’est pas de décider s’il faut l’installer. Elle consiste à trouver un créneau pour une migration urgente de base de données sur une plateforme que les développeurs utilisent peut-être déjà pour gérer les mises en production en cours. Une instance à nœud unique doit s’arrêter jusqu’à la fin de cette opération.

Attendre un créneau de maintenance plus calme laisse plus longtemps ouverte une faille activement exploitée. Effectuer immédiatement la mise à jour peut interrompre l’accès aux dépôts, aux demandes de fusion et à d’autres activités de développement. Les installations à plusieurs nœuds offrent davantage de souplesse, mais GitLab exige toujours la séquence de mise à niveau correcte; disposer de plusieurs machines ne fait pas disparaître la modification de la base de données.

Pour les lecteurs de BTW, cet incident rend visible le coût opérationnel d’une infrastructure de développement autogérée. L’organisation assume la fenêtre de maintenance d’urgence aussi bien que les serveurs. La mise à jour de sécurité a déjà été prise en charge pour les clients de GitLab.com et de GitLab Dedicated, tandis que les opérateurs d’installations autogérées doivent intégrer le même correctif à leur propre calendrier de mises en production puis rétablir proprement le service.

À surveiller

Il faudra vérifier que les opérateurs d’installations autogérées confirment à la fois l’installation d’une version corrigée et l’achèvement réussi de la migration de base de données. Des mises à niveau retardées, des échecs de migration ou de nouvelles consignes de GitLab montreraient où les travaux de sécurité urgents se heurtent aux calendriers de développement. Des preuves d’exploitation avant l’application du correctif ajouteraient une tâche distincte de réponse à incident.