GitLab : un nouveau correctif critique pour les installations autonomes

Une nouvelle faille permet potentiellement d’exécuter du code

GitLab a publié le 21 octobre 2026 des mises à jour de sécurité pour ses éditions Community Edition et Enterprise Edition. La vulnérabilité critique CVE-2026-110264 peut permettre, sous certaines conditions, à une personne non authentifiée d’exécuter du code sur le serveur. Elle provient d’un dépassement d’entier (un calcul dépassant la plage de nombres que le programme peut représenter) lors de la compilation (la préparation pour l’exécution) d’une expression régulière (un motif servant à rechercher ou reconnaître du texte). Bulletin GitLab du 21 octobre.

Cette faille est distincte de CVE-2026-97229, corrigée dans la publication du 12 octobre. Une installation mise à jour à cette occasion peut donc encore nécessiter une intervention. Publication précédente.

Les installations administrées par l’entreprise sont concernées

Pour cette nouvelle faille, le bulletin couvre les versions depuis GitLab 7.0 jusqu’aux bornes corrigées suivantes : 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 et 19.5.1, chacune dans sa branche (sa série de versions). Les versions antérieures à ces bornes sont touchées. GitLab a exceptionnellement reporté ce correctif sur plusieurs branches anciennes.

GitLab.com utilise déjà une version corrigée. Pour GitLab Dedicated, les clients exécutant 19.3.5-internal0, 19.4.2-internal0 ou une version ultérieure disposent déjà des corrections et n’ont pas d’action à mener pour cette publication. Ces exceptions ne s’étendent pas aux installations autonomes. Périmètre officiel.

Les correctifs sont disponibles depuis le 21 octobre

L’éditeur recommande une mise à jour immédiate ; il ne fixe pas de date limite calendaire. Sur une installation à un seul nœud (une seule machine participant au fonctionnement de GitLab), cette publication entraîne une interruption pendant la migration de la base de données (la modification de sa structure pour la nouvelle version). Sur plusieurs nœuds, une mise à jour sans interruption est possible à condition de respecter la procédure adaptée.

Le bulletin précise que les versions 19.4.3 et 19.3.6 comportent des migrations pendant la mise à jour ; 19.4.3 comprend aussi des migrations après déploiement (après la mise en place de la nouvelle version). Contraintes de migration.

Faire vérifier la version et préparer l’intervention

• Identifier la version installée : après connexion, ouvrir Help puis Help dans la barre latérale ; la version figure en haut de la page. Procédure officielle.
• Faire déterminer la version cible et le chemin de mise à jour, avec les éventuels paliers obligatoires et les notes de compatibilité ; ne pas présumer qu’un saut direct convient à votre installation.
• Préparer une sauvegarde et un retour arrière (le rétablissement de l’état fonctionnel précédent), en incluant les secrets (les données confidentielles nécessaires au fonctionnement de GitLab) et fichiers de configuration (les fichiers contenant ses réglages). Tester le plan dans une copie de l’environnement de production (l’installation utilisée au quotidien) selon les recommandations de GitLab.
• Planifier l’interruption et les migrations selon l’architecture, puis appliquer les correctifs sans attendre une échéance qui n’existe pas dans le bulletin.
• Contrôler le fonctionnement avant et après l’intervention : connexion, accès aux projets, récupération et envoi du code ; si vous utilisez l’intégration et le déploiement continus (l’automatisation des vérifications du code et de sa mise en service), vérifier également la prise en charge des tâches par les exécuteurs (les logiciels chargés de les lancer). Préparation et vérifications.

Pour l’entretien des protections de ce périmètre, VCSTS entretient les protections qui lui sont confiées, notamment les mises à jour des composants couverts.