Hier, GitLab a publié en urgence les versions 19.4.2, 19.3.5 et 19.2.8 pour corriger une faille un peu chaude avec un score CVSS de 10 sur 10 . Référencée sous le code CVE-2026-97229, elle permet à quelqu'un sans compte user d'exécuter du code sur le serveur en glissant tout simplement une expression régulière piégée dans une configuration CI/CD.

GitLab précise que cela ne peut se faire que "sous certaines conditions" sans préciser lesquelles, et il ne dit pas non plus comment un inconnu pourrait faire lire sa config CI forgée par une instance. Gitlab mentionne une histoire de dépassement d'entier dans le compilateur de regex du CI/CD et d'une validation insuffisante des expressions mais on n'a pas les détails techniques qui sortiront dans environ 90 jours. C'est habituel pour laisser le temps à tout le monde de patcher.

Ces dernières semaines, ça enchaine fort ( un peu comme Citrix ) avec fin septembre, la 19.4.1 qui corrigeait déjà deux autres faille sur le même terrain : CVE-2026-93577, pour un dépassement d'entier dans le compilateur, et CVE-2026-89078, pour un double free dans l'analyseur de regex. Notées 9,9 toutes les deux et signalées par le même chercheur (joaxcar), mais celles-là exigeaient au moins un compte. Et la troisième faille (la CVE-2026-85706) découverte aussi courant septembre, était quand a elle aussi notée 10 sur 10 et permettait de lire les fichiers présents sur le serveur sans avoir de compte.

Alors qui est concerné ?

Hé bien toutes les instances auto-hébergées en 19.2 avant la 19.2.8, en 19.3 avant la 19.3.5 et en 19.4 avant la 19.4.2. Une 19.4.1 installée fin septembre n'est donc pas à l'abri. Le service GitLab.com en lui-même est déjà à jour et les clients serveur dédié n'ont rien à faire. Mais pour les autres, l'alerte de sécurité ne mentionne aucun contournement / fix. Faut juste mettre à jour et basta.

Sur une instance mono-nœud, prévoyez donc une coupure, parce que ce correctif embarque des migrations de base qui exigeront un reboot.

Voilà, maintenant que vous êtes au jus, c'est le moment de patcher !!

Source : BleepingComputer .

Si vous développez pour AWS, il y a de bonnes chances que LocalStack tourne déjà quelque part dans votre docker-compose ou votre CI. C'est un peu l'outil incontournable pour tester ses buckets S3 et ses fonctions Lambda sans avoir à toucher au vrai cloud. Sauf que depuis mars dernier, ses nouvelles versions exigent un compte LocalStack et un jeton d'authentification, CI comprise, et surtout l'édition Community n'est plus prise en charge.

Ouin !

Et comme si ça ne suffisait pas, l'offre gratuite qui reste interdit totalement l'usage commercial. Donc si vous l'utilisez dans le cadre de votre travail, faudra passer à la caisse. Alors, oui, ne pas respecter la licence ou se figer sur une ancienne image reste possible, mais déjà, ça ne se fait pas, et ensuite, niveau faille de sécu, ce n'est pas top.

Mais c'est là qu'arrive en sauveur Floci, un émulateur AWS local sous licence MIT qui se présente comme un remplaçant direct de LocalStack, sans avoir besoin de se créer un compte ou un jeton et surtout sans offre payante planquée dedans.

Maintenant, le principe reste le même puisque vous pointez dessus l'AWS CLI (Floci écoute sur le port 4566), vos SDK, Terraform, OpenTofu ou le CDK, avec la région de votre choix et des identifiants bidon, et vos commandes habituelles tomberont sur votre machine au lieu de partir chez Amazon.

Le plus simple pour démarrer, c'est sa CLI qu'on peut déployer avec Homebrew (il y a aussi un script pour Linux et un pour Windows) :

brew install floci-io/floci/floci
floci start
eval $(floci env)
aws s3 mb s3://my-bucket

Ensuite, faites un floci start pour lancer l'émulateur dans un conteneur et lui monter le socket Docker de votre machine. Floci s'appuie sur de vrais conteneurs dès que la fidélité l'exige ce qui fait que Lambda tourne dans l'image d'exécution officielle d'AWS, RDS lance un vrai PostgreSQL, MySQL ou MariaDB, ElastiCache un Valkey, et c'est pareil pour ECS, EC2 ou EKS.

J'ai fait l'essai sur mon Mac avec un bucket S3, une table DynamoDB et une petite fonction Lambda en Python, et tout a répondu du premier coup à la CLI AWS. La Lambda a juste mis six secondes à répondre au premier appel, puis moins d'une seconde au suivant.

Pour voir ce qui se passe ensuite, une console web est dispo localhost:4566/_floci/ui, avec vos ressources rangées par service.

La console web de Floci sur localhost, après un essai sur S3, DynamoDB et Lambda

Notez aussi que si vous venez de LocalStack, la bascule se résume simplement dans le nom de l'image puisque Floci traduit tout seul les variables d'environnement de LocalStack, exécute sans modification les scripts d'init rangés dans /etc/localstack/init/ et répond même sur /_localstack/health. Cela veut dire qu'une CI qui attend ce signal ne voit pas la différence et ça c'est super cool pour migrer vite fait bien fait.

Et si vos scripts appellent aws ou boto3, prenez l'image floci/floci:latest-compat, qui embarque les deux.

Par contre, méfiez-vous du volume de données, car LocalStack range tout par défaut dans /var/lib/localstack et Floci dans /app/data. Donc dans le docker compose, pointez bien votre volume sur /app/data sinon, vous perdrez vos fichiers au premier restart du docker.

Après n'oubliez pas non plus que Floci imite le comportement d'AWS, et pas sa sécurité. En effet, par défaut, il n'applique aucune politique IAM, donc si vous voulez vérifier qu'un rôle trop resserré bloque bien une action, il faudra activer la variable FLOCI_SERVICES_IAM_ENFORCEMENT_ENABLED. Et certains services ne sont également que des façades. Par exemple Bedrock Runtime renvoie des réponses factices et Transcribe termine ses tâches aussitôt, sans jamais traiter l'audio, donc oui, votre code peut les appeler, mais le résultat ne sera pas au rendez-vous, ce qui est tout à fait normal.

Pour le reste, les données sont stockées en mémoire par défaut et s'effaceront à l'arrêt, ce qui est pile poil ce qu'on veut en CI. Vous pouvez quand même le paramétrer pour que ça s'écrive sur le disque si vous voulez...

Voilà, à essayer sur une branche de votre CI si vous voulez vous débarrasser de débrancher LocalStack pour de bon !

Source : Floci sur GitHub

GitLab a sorti hier (lundi 17 août), un correctif d'urgence , complètement en dehors de son calendrier habituel, pour une faille qui permet à quelqu'un sans compte ni mot de passe de modifier ou de supprimer vos projets publics et des données utilisateur. Hé ouais c'est chaud et c'est pour ça que son score CVSS est de 9,4 sur 10.

5 jours plus tôt, le 12 août, GitLab publiait son patch de routine pour la 19.2, 19.1 et 19.0. C'est un périmètre normal puisque sa politique de maintenance ne couvre que la version stable et les deux précédentes. Mais comme là, on est dans l'exceptionnel, ce correctif du 17 août en couvre une quatrième, la 18.11, dont le support avait pris fin le 16 juillet dernier. Ils sont allés rouvrir une branche morte juste pour patcher ce GROS problème !

La faille elle-même, on n'en sait presque rien par contre. Estampillée CVE-2026-19478, c'est une histoire de directive GraphQL, mais GitLab ne dit ni laquelle, ni dans quelles conditions ça se déclenche. Les détails techniques sortiront vers la mi-novembre, c'est-à-dire 90 jours après le correctif, comme d'habitude, histoire d'être sûr que tout le monde ait patché son install.

Maintenant, la bonne nouvelle c'est que si vous êtes sur GitLab.com ou sa version Dedicated , vous n'avez rien à faire, puisque c'est déjà patché. En fait cette histoire ne concerne que les instances auto-hébergées.

Et parmi elles, tout le monde n'est pas impacté de la même manière. En effet, le vecteur d'attaque passe par le réseau et vise les projets publics. Cela veut dire que votre instance planquée derrière un VPN, sans visibilité publique, risque beaucoup moins que celle qui expose ses dépôts à Internet.

Ensuite, pour la mise à jour, ça dépend d'où vous partez. Entre la 18.2 et la 18.10, aucun correctif n'existe sur votre branche. Il faudra upgrader jusqu'à la 18.11.11, en vous arrêtant aux paliers de 18.5 et 18.8 s'ils sont sur votre route.

Si vous tournez déjà en 18.11, prenez la 18.11.11. Sur une 19, c'est 19.0.8, 19.1.6 ou 19.2.4. Et plus ancien que 18.2 ? Bah là, GitLab ne liste pas ces versions parmi les affectées, mais elles ne reçoivent plus de correctif depuis un bon moment, donc ce serait bien de mettre à jour quand même, hein...

Pour le moment, personne n'a signalé d'attaque et aucun exploit ou PoC n'a fait surface sur GitHub. Ça ne veut pas dire grand-chose, je vous l'accorde mais on se rassure comme on peut...

Allez, bon courage !

Source : The Hacker News

GitHub’s new Actions safeguard pauses potentially malicious workflow runs before execution, leaving repository owners to decide who can approve them and what checks must come first.

The post GitHub Automatically Holds Suspicious Actions Runs, but Repository Owners Must Approve Them appeared first on TechRepublic.

JetBrains has patched CVE-2026-63077, a critical TeamCity flaw that could let unauthenticated attackers execute server commands and compromise connected CI/CD pipelines.

The post Critical TeamCity Flaw Could Let Unauthenticated Attackers Execute Server Commands appeared first on TechRepublic.