CISA Alerte : GitLab expose des dizaines de milliers d'instances et exige un patch SSRF CVE-2021-39935

La United States Agency for Infrastructure and Cybersecurity (CISA) a donné un ultimatum : les organismes fédéraux doivent garer leurs exemples GitLab pour une vulnérabilité corrigée il y a des années, mais qui est maintenant activement exploitée dans des environnements réels. Il s'agit d'une défaillance de type SSRF (Server-Side Request Forgery) connue sous le nom de CVE-2021-39935, que GitLab a initialement résolu en décembre 2021.

Dans cette correction, GitLab a expliqué que le problème affecte l'API CI Lint, l'outil qui permet de valider et de simuler les pipelines CI / CD, et que dans certains paramètres - lorsque l'enregistrement des utilisateurs est limité - les utilisateurs extérieurs sans privilèges peuvent exécuter des requêtes du serveur. L'avis technique original est disponible dans la note de sécurité de GitLab de décembre 2021: Communiqué de sécurité de GitLab (06-12-2021) et les détails de l'AQE peuvent être trouvés dans la base de données NVD: CVE-2021-39935 (NVD).

Ce qui a ravivé les alarmes, c'est que la CISA a inclus cette vulnérabilité dans son catalogue de vulnérabilités connues et exploitées dans le monde réel, et a imposé un délai aux organismes civils fédéraux pour mettre en place des correctifs : trois semaines depuis la notification, avec un délai du 24 février 2026, conformément à la directive opérationnelle contraignante BOD 22-01. Le message de la CISA est clair : ces échecs restent une passerelle fréquente pour les acteurs malveillants et nécessitent une attention immédiate. L'inclusion dans le catalogue CISA est disponible ici: CISA - Alerte CVE-2021-39935, et la liste publique des vulnérabilités exploitées est dans: Catalogue des vulnérabilités exploitées. La directive qui exige des mesures peut également être révisée sur le site Web de la CISA sur la DBO 22-01 : Directive opérationnelle contraignante 22-01.

Au-delà du cadre fédéral, la CISA a exhorté les entreprises et les organisations privées à privilégier la médiation, car l'exposition est réelle et quantifiable. Le moteur de recherche d'appareils connectés à Shodan montre des dizaines de milliers de cas avec l'empreinte accessible au public de GitLab : plus de 49 000 résultats et près de 27 000 réponses par défaut dans le port 443, selon les recherches publiques de Shodan. Recherche GitLab à Shodan et résultats dans le port 443.

Il est facile de comprendre pourquoi la priorité est élevée: GitLab est une plateforme très répandue dans le monde du développement. La société déclare des dizaines de millions d'utilisateurs et une présence importante parmi les grandes entreprises, donc une vulnérabilité dans son domaine de gestion et CI / CD a un potentiel d'impact massif. Plus d'informations sur la présence de GitLab dans le secteur est sur son site corporatif: À propos de GitLab.

Que doivent faire les responsables techniques et de sécurité? La première étape est évidente et urgente : mettre à jour les versions corrigées de GitLab en suivant les instructions du fabricant. Si la mise à jour n'est pas immédiate, appliquer des mesures d'atténuation officielles, restreindre l'accès aux IPA exposées et réduire au minimum l'exposition du public sont des mesures temporaires nécessaires. Il convient également de vérifier les dossiers, de faire pivoter les pouvoirs qui ont pu être compromis et d'examiner les règles de pare-feu et les contrôles d'accès afin d'empêcher les services internes de recevoir des demandes forcées de composants exposés.

Dans la pratique, il peut s'agir de désactiver l'accès du public à l'API CI Lint si ce n'est strictement nécessaire, de déployer des listes IP blanches, de forcer l'authentification renforcée sur les panneaux administratifs et de surveiller les modes de circulation inhabituels et les exécutions de pipelines. Si une équipe détecte une activité suspecte et ne peut pas atténuer l'échec, l'option responsable est de cesser temporairement d'utiliser l'instance touchée pour appliquer la correction ou passer à une solution de rechange sûre.

L'émergence d'exploitations efficaces contre un défaut corrigé il y a des années rappelle une leçon classique de cybersécurité : les corrections ne sont efficaces que si elles sont appliquées. Une vulnérabilité corrigée reste dangereuse tant que des installations non mises à jour existent. La pression exercée par l'ACIS sur les entités fédérales vise à réduire cette lacune, mais il incombe aussi aux gestionnaires de systèmes et aux fournisseurs externes de maintenir à jour leur environnement de développement et de prestation continue.

Enfin, il convient de placer cet épisode dans un contexte plus large : cette même semaine, la CISA a émis plusieurs avertissements et ordonné des correctifs pour d'autres défaillances critiques exploitées sur le terrain. Pour l'équipement de sécurité, cela signifie prioriser la gestion des patchs, identifier les actifs exposés et établir des processus qui raccourcissent le temps entre la publication d'un patch et son déploiement efficace.

Si vous voulez lire les sources officielles citées dans cet article, voici les principaux liens: Note de GitLab sur la correction ( GitLab - Communiqué de sécurité), l'enregistrement du CEV dans le NVD ( NVD - CVE-2021-39935), l'alerte de la CISA qui intègre la vulnérabilité au catalogue ( CISA - alerte (03-02-2026)), la liste publique des vulnérabilités exploitées ( KEV Catalogue) et une vue sur l'exposition Shodan ( Shodan - GitLab).

La recommandation finale est simple : ne croyez pas qu'un vieux patch n'est plus pertinent. Si votre organisation exécute GitLab, vérifiez les versions et appliquez les corrections dès que possible. L'industrie et les organismes gouvernementaux le font, maintenant c'est aux autres.