Un serveur GitLab installé il y a quelques années, puis oublié dans un coin du réseau, peut ouvrir la porte de votre entreprise. Le 21 octobre 2026, l’éditeur a en effet corrigé une faille critique GitLab qui obtient la note maximale de 10 sur 10. Elle touche toutes les versions depuis la 7.0, soit douze ans de logiciel. Pour une PME qui développe ses outils ou automatise ses déploiements, le danger reste très concret.
Selon le rapport Verizon DBIR 2026, l’exploitation de failles constitue désormais le premier vecteur d’intrusion, devant le phishing. Voici ce qu’il faut vérifier, et ce que cet épisode enseigne à toute entreprise qui héberge ses propres logiciels. Pour un premier tour d’horizon, notre check-list cybersécurité pour les PME reste un bon point de départ.
La CVE-2026-110264 est une vulnérabilité de GitLab Community Edition et Enterprise Edition qui obtient la note de 10 sur 10 (CVSS). Elle permet à un attaquant distant, sans identifiant, d’exécuter du code sur le serveur. Elle touche toutes les versions depuis la 7.0. Les correctifs du 21 octobre 2026 portent les numéros 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 et 19.5.1. Une instance en 18.10 ou antérieure doit migrer vers une branche maintenue. GitLab.com dispose déjà du correctif.
La CVE-2026-110264 est un dépassement d’entier dans Onigmo, le moteur d’expressions régulières qu’emploie GitLab. Selon Le Monde Informatique, il suffit que le serveur affiche un fichier Org-mode spécialement préparé pour déclencher la faille. L’attaquant peut alors exécuter du code avec les droits du compte système « git ».
Trois éléments expliquent la note maximale. D’abord, l’attaque ne demande aucune authentification. Ensuite, elle se mène à distance. Enfin, le périmètre reste immense, puisque la faille remonte à GitLab 7.0, sortie en 2014.
Cette alerte suit par ailleurs une autre faille notée 10 sur 10, la CVE-2026-97229, corrigée le 12 octobre 2026. Les deux exploitent un problème proche, mais par des points d’entrée différents. Autrement dit, une entreprise qui a appliqué le correctif du 12 octobre reste exposée à celle du 21 octobre. Le scénario rappelle celui des mises à jour Windows et de leurs correctifs successifs : un correctif ne vaut que jusqu’au suivant.
GitLab ne concerne pas que les grands groupes. Une agence web, un éditeur de logiciels ou un bureau d’études l’installent souvent sur un serveur interne ou loué. L’alerte vise précisément ce cas, celui de l’instance auto-hébergée.
Le danger dépasse alors le code source. Dans une PME, GitLab centralise souvent les pipelines de déploiement, les jetons d’accès et les mots de passe de production. Un attaquant qui prend la main sur ce serveur peut donc modifier une application livrée à des clients. Il peut aussi récupérer des identifiants ou rebondir vers d’autres machines. D’où l’importance de la sécurité des serveurs et des systèmes en entreprise.
Les chiffres confirment la tendance. Selon le rapport Verizon DBIR 2026, qui couvre la période de novembre 2024 à octobre 2025, l’exploitation de failles explique 31 % des intrusions. Le phishing pèse 16 %. Le même rapport mesure aussi un délai médian de 43 jours entre la détection d’une faille et sa correction complète, ce qui laisse largement le temps d’agir à un attaquant. En France, l’ANSSI a traité 1 366 incidents en 2025, selon son panorama de la cybermenace de mars 2026.
Une instance GitLab vulnérable expose l’entreprise à quatre risques principaux :
À ce jour, aucun signalement public ne fait état d’une exploitation active. Pourtant, l’absence de signalement ne prouve pas l’absence d’attaque. Le CERT-EU recommande ainsi de rechercher des signes de compromission, en priorité sur les serveurs joignables depuis Internet. Une compromission impose ensuite de suivre un plan de reprise d’activité préparé à l’avance.
La réponse tient en cinq étapes, à mener rapidement et dans cet ordre.
Cette faille illustre un problème plus large que GitLab. Beaucoup de PME installent un logiciel, le configurent, puis n’y touchent plus tant qu’il fonctionne. Le même schéma vaut pour les NAS, les VPN ou les logiciels métier hébergés en interne.
Une politique de mise à jour efficace repose sur trois habitudes. Il faut un inventaire complet des logiciels exposés, une veille sur les alertes et un calendrier de correctifs. Lorsque l’entreprise ne dispose pas d’informaticien, ces tâches passent vite au second plan. L’infogérance et la maintenance informatique servent justement à les rendre systématiques. Pour les structures concernées, cette discipline devient même une exigence, comme l’explique notre article sur NIS2 et l’infogérance.
Le Groupe Izitek, basé à Éguilles près d’Aix-en-Provence, accompagne les entreprises de PACA et de toute la France en cybersécurité. Face à une alerte comme celle de GitLab, plusieurs entités du groupe peuvent intervenir.
DG Conseil, la société du groupe dédiée à la cybersécurité, dispose du label ExpertCyber. Elle réalise l’audit des serveurs exposés et la recherche de traces de compromission depuis ses bureaux de La Penne-sur-Huveaune, près de Marseille.
De son côté, Like-IT, notre offre d’informaticien à temps partagé, assure le suivi courant. Un référent dédié tient l’inventaire à jour, surveille les alertes et planifie les mises à jour, selon une approche préventive.
Enfin, les équipes Izitek mettent en place les briques qui limitent l’impact d’un incident. Cela comprend la sauvegarde et la reprise après sinistre, la segmentation du réseau et des infrastructures, ainsi que l’hébergement sécurisé.
Une gestion des correctifs bien organisée se mesure avec quelques indicateurs simples :
Le délai d’application reste le plus parlant. Selon Verizon, la médiane atteint 43 jours. Viser quelques jours pour les failles critiques réduit alors fortement la fenêtre d’exposition. Pour comparer les options, consultez aussi notre article infogérance ou informaticien interne.
Exemple illustratif : un bureau d’études de quinze personnes, près d’Aix-en-Provence, utilise GitLab depuis 2019. Le serveur tourne encore en version 16 et reste accessible depuis Internet. Personne ne l’a mis à jour depuis le départ du technicien qui l’avait configuré.
Dans ce cas, la marche à suivre est claire. Il faut d’abord couper l’accès public, puis sauvegarder les dépôts et migrer vers la branche 19.5.1. Ensuite, le bureau d’études renouvelle les jetons et rétablit l’accès distant par VPN. Pour éviter une récidive, il confie enfin le suivi des mises à jour à un prestataire informatique dans les Bouches-du-Rhône.
La faille critique GitLab du 21 octobre 2026 concerne d’abord les entreprises qui hébergent leur propre instance. Son message vaut pourtant pour toutes les PME : un logiciel exposé et jamais mis à jour finit par devenir une porte d’entrée. Recenser, corriger, sauvegarder et surveiller restent les quatre réflexes décisifs.
Vous souhaitez savoir quelles actions prioriser dans votre entreprise ? Contactez Izitek pour échanger sur votre environnement. Ensemble, nous identifierons une feuille de route adaptée à vos enjeux, votre activité et votre budget.
Non, pas pour cette faille, car GitLab indique que ses services hébergés disposent déjà du correctif. L’alerte vise les instances installées sur vos propres serveurs ou chez un hébergeur. Vérifiez tout de même que vos comptes utilisent la double authentification, puisque le vol d’identifiants reste une menace distincte.
Examinez les journaux, en particulier les plantages des processus Onigmo et les erreurs d’affichage Org-mode. GitLab a aussi publié deux règles de détection. En cas de doute, faites appel à un spécialiste. Une compromission laisse parfois des traces discrètes, comme un nouveau compte administrateur ou un jeton récent.
Non, il ne protège pas contre la CVE-2026-110264. Les deux failles touchent le traitement des expressions régulières, mais par des chemins différents. Une instance mise à jour le 12 octobre doit donc passer à l’une des versions publiées le 21 octobre.
Le plus sûr consiste à l’arrêter, après avoir archivé les dépôts utiles. Un serveur oublié mais allumé reste une cible, surtout s’il reste joignable depuis Internet. Si vous devez conserver le service, migrez-le vers une version maintenue ou vers une solution cloud hébergée.
Oui, à condition de s’organiser avec un inventaire, les alertes de l’éditeur et un créneau mensuel. Dès que l’entreprise héberge des serveurs exposés, un prestataire devient toutefois plus sûr. Certaines aides publiques financent d’ailleurs une partie de la démarche, comme le détaille notre article sur les dispositifs d’aide à la cybersécurité en 2026.
Oui, et de plus en plus vite. Lorsqu’un éditeur publie un correctif critique, celui-ci aide aussi les attaquants à comprendre où frapper. L’intelligence artificielle accélère encore ce travail, comme le montre notre analyse des attaques assistées par IA contre les PME. Mieux vaut donc corriger en jours plutôt qu’en semaines.
