Une faille GitLab notée CVSS 10.0 permettrait d'exécuter du code à distance sans authentification. Mettez à jour.

GitLab a publié des correctifs pour une faille GitLab de gravité maximale. Elle touche également les éditions Community Edition (CE) et Enterprise Edition (EE). En effet, selon l’éditeur, un utilisateur non authentifié pourrait, dans certaines conditions, exécuter du code arbitraire sur le serveur.

Le score CVSS atteint 10.0, le plus élevé possible. Autrement dit, les administrateurs doivent traiter ce correctif en priorité.

Une faille GitLab de gravité maximale

L’éditeur explique avoir corrigé un problème qui pouvait permettre une exécution de code à distance. En effet, l’attaquant n’aurait pas besoin de compte sur l’instance visée. Il lui suffirait d’exploiter une expression régulière spécialement conçue, liée au fonctionnement du CI/CD.

Les informations disponibles restent limitées. En effet, elles ne précisent ni l’identifiant CVE ni les versions exactes concernées. Il faut donc consulter le bulletin de sécurité officiel de GitLab avant d’agir.

Par ailleurs, rien n’indique à ce stade que la vulnérabilité soit exploitée activement. Cependant, un score de 10.0 incite à ne pas attendre.

Ce que signifie un score CVSS de 10.0

Le score CVSS mesure la gravité d’une vulnérabilité sur une échelle de 0 à 10. Un 10.0 correspond au pire scénario. Ainsi, ce niveau est généralement réservé aux failles exploitables à distance, sans authentification et avec un impact complet.

Ainsi, trois éléments expliquent cette note :

• l’attaquant n’a pas besoin d’être connecté ;
• il peut exécuter du code arbitraire sur le serveur ;
• les deux éditions, CE et EE, sont également concernées.

De plus, l’exécution de code sur un serveur donne souvent un contrôle étendu. Il peut ensuite lire des données, modifier des fichiers ou rebondir vers d’autres systèmes.

Pourquoi la faille GitLab inquiète les équipes DevOps

GitLab centralise le code source, les pipelines et parfois les secrets de déploiement. Par conséquent, la compromission d’une instance dépasse largement un simple serveur web. Elle peut toucher toute la chaîne de développement.

Par exemple, un serveur GitLab stocke souvent des jetons d’accès, des clés de déploiement et des variables d’environnement. Un attaquant qui prend la main sur la machine pourrait tenter de les récupérer. Il pourrait ensuite s’en servir pour accéder à des environnements de production.

Le code source constitue une autre cible. Il peut contenir de la propriété intellectuelle ou des informations sensibles. En outre, une modification discrète d’un dépôt ou d’un pipeline devient possible. Elle ouvre la voie à une attaque sur la chaîne d’approvisionnement logicielle.

L’élément lié aux expressions régulières mérite également l’attention. Ces motifs servent à filtrer ou à valider des données. Pourtant, mal traités, ils peuvent devenir un point d’entrée inattendu. Les développeurs les considèrent souvent comme anodins.

Recommandations pour les administrateurs

Les instances GitLab auto-hébergées sont les plus exposées. Les administrateurs gèrent eux-mêmes les mises à jour. Ils doivent donc agir sans délai.

1. Consulter le bulletin officiel de GitLab pour identifier l’identifiant CVE et les versions corrigées.
2. Appliquer le correctif sur toutes les instances CE et EE, y compris les environnements de test.
3. Limiter l’exposition : restreindre l’accès à Internet si l’instance n’a pas besoin d’être publique.
4. Examiner les journaux à la recherche de requêtes inhabituelles ou de pipelines suspects.
5. Renouveler les secrets (jetons, clés, variables CI/CD) si un doute existe sur une compromission.

Enfin, il est utile de vérifier l’inventaire des instances. Les serveurs oubliés ou peu surveillés sont souvent les premiers à être visés. Ainsi, un simple contrôle peut éviter une mauvaise surprise.

Ce qu’il faut retenir

• GitLab a corrigé une vulnérabilité notée CVSS 10.0 dans ses éditions CE et EE.
• Un utilisateur non authentifié pourrait exécuter du code arbitraire sur le serveur.
• Le mécanisme repose sur une expression régulière spécialement conçue, dans le contexte du CI/CD.
• Les détails techniques complets figurent dans l’avis officiel de l’éditeur.
• La mise à jour doit être appliquée rapidement, notamment sur les instances auto-hébergées.

Cette affaire rappelle une réalité simple. En effet, les plateformes de développement sont des cibles de choix. Il est donc essentiel de les mettre à jour et de les isoler avec le même soin que les systèmes de production.

Source : GitLab Patches CVSS 10.0 Flaw That Could Let Unauthenticated Users Run Server Code