Le 14 octobre 2026, GitHub a ouvert en aperçu public les lockfiles de workflow : chaque action et workflow réutilisable est épinglé sur un commit précis, de sorte que le code relu est le code exécuté. Activez le verrouillage sur vos dépôts critiques avant qu’un tag déplacé n’introduise du code malveillant dans votre CI.

Le 12 octobre 2026, GitLab a publié un correctif critique refermant 24 failles, dont CVE-2026-97229, un débordement d’entier à CVSS 10,0 dans le compilateur d’expressions régulières du CI/CD, exploitable sans authentification. Tout administrateur d’une instance auto-hébergée doit passer en 19.4.2, 19.3.5 ou 19.2.8 sans attendre, car cette faille ne demande même plus de compte.

Le 8 octobre 2026, l’ambassadeur CNCF Mauro Morales pose la question qui hante les équipes plateforme : sous quelles conditions confier l’exploitation d’une machine à un agent autonome. Sa réponse tient en un principe : hôte immuable, isolation de la charge et proposition d’état qui passe par la forge logicielle.

La campagne GhostAction compromet des comptes mainteneurs pour pousser un faux workflow de « sécurité » qui exfiltre les secrets CI/CD vers une IP contrôlée. Vérifiez vos dépôts pour les fichiers security-audit.yml et github_actions_security.yml, puis révoquez les identifiants concernés.

GitHub annonce la disponibilité générale des pull requests empilées, qui découpent une grosse évolution en petites demandes revues indépendamment puis fusionnées ensemble. Si vos branches se bloquent les unes les autres, les chiffres de GitHub — 9 % de code fusionné en plus, 5 % de délai de fusion en moins — justifient de les adopter dès maintenant.

GitHub retirera l’image de runner macOS 14 le 2 novembre 2026 et fait déjà échouer les jobs qui l’utilisent encore pendant huit fenêtres de brownout réparties sur octobre. Migrez vos workflows vers un label arm64 — macos-15 ou macos-latest — avant la prochaine coupure du 12 octobre.

Le 17 septembre 2026, GitHub annonce que le label ubuntu-latest passe d’Ubuntu 24.04 à 26.04, avec un déploiement progressif entre le 19 octobre et le 19 novembre 2026. La migration embarque un saut de JDK de 17 à 25, des sauts de version majeure pour Docker Compose et Helm, et la suppression d’une douzaine d’outils préinstallés : les workflows qui ne pinent pas leur runtime vont casser.

Gitea abandonne le préfixe « 1. » et publie la 28.0.0, une version majeure qui change la sortie réseau des opérations Git et corrige plusieurs failles d’autorisation. Une montée de version à planifier, pas à appliquer à l’aveugle.

Le 23 septembre 2026, GitLab a publié un correctif critique pour 19.4.1, 19.3.3 et 19.2.7, refermant deux exécutions de code à distance à CVSS 9,9 dans l’analyseur d’expressions régulières du pipeline, déclenchables par un simple fichier .gitlab-ci.yml forgé. Tout utilisateur authentifié capable d’éditer une configuration CI/CD devient un vecteur : corrigez les instances auto-hébergées immédiatement.

Les actions actions-cool/issues-helper et maintain-one-comment, compromises le 18 mai 2026 dans la campagne Mini Shai-Hulud, ont été réactivées le 16 septembre avec des tags pointant toujours vers le code malveillant, selon Socket. La leçon est brutale : en CI/CD, un tag mutable est une porte laissée ouverte.

Le 24 septembre 2026, Aikido a révélé que les adresses « Email work item to this project » de GitLab, générées avec un jeton longue durée et publiées par erreur dans des README, laissent un attaquant créer des merge requests ou pousser du code à la place du titulaire. Cherchez ces adresses dans vos dépôts et réinitialisez les jetons exposés.

GitHub a durci l’application de la version minimale des runners auto-hébergés : des brownouts ont commencé le 14 septembre et, à partir du 25 septembre 2026, tout runner non mis à jour sous 30 jours ne reçoit plus aucun job. L’échec est silencieux — les jobs restent « Queued » sans erreur : auditez vos runners avant la prochaine fenêtre.

GitLab a publié le 10 septembre 2026 les versions 19.3.2, 19.2.6 et 19.1.8 pour corriger dix-huit failles, dont une lecture de fichier arbitraire sans authentification via l’API des commits et une désérialisation notée CVSS 9,9. Toute instance auto-hébergée exposée doit être mise à jour sans attendre, et les secrets des variables CI/CD passés en revue.

Le 3 septembre 2026, GitHub a livré trois mises à jour de GitHub Actions : une permission vulnérabilités pour GITHUB_TOKEN, le contexte job des workflows réutilisables et une API de dépréciation des runners. Remplacez vos portées larges par la permission vulnérabilités et adoptez job.workflow_ref dans vos workflows réutilisables.

Face aux détournements de tags qui ont frappé tj-actions et 23 000 dépôts, GitHub déploie une feuille de route de sécurité pour Actions : lockfiles de dépendances, secrets scopés et pare-feu d’égression. Deux mesures sont déjà disponibles : l’épinglage par SHA et l’OIDC.

Le 16 juillet 2026, Docker Engine 29.6.2 a corrigé cinq vulnérabilités de BuildKit, dont la CVE-2026-15793 qui permet d’exécuter des commandes sur l’hôte lors du checkout d’une source Git malveillante, puis la CVE-2026-17106 a été corrigée dans la 29.7.0. Les pipelines qui construisent à partir de sources non maîtrisées doivent mettre à jour Engine, Buildx et BuildKit sans attendre.

À partir du 1er octobre 2026, GitHub applique à la rétention des checks, des workflow runs et des statuses le même réglage que celui des artefacts et des logs, soit 90 jours par défaut au lieu de plus de 400. Les équipes qui s’appuient sur cet historique doivent vérifier leur réglage et exporter ce qu’elles veulent conserver.

Début août 2026, GitHub a livré une permission « vulnerability-alerts: read » qui autorise le jeton de CI à consulter les alertes Dependabot sans recourir à un PAT surdimensionné. Les workflows qui automatisent la remédiation des vulnérabilités peuvent enfin appliquer le moindre privilège jusqu’au bout.

Le 26 août 2026, GitLab publie un correctif pour CVE-2026-18252, une faille de l’agent IA Duo Claude qui permet à un développeur authentifié d’exécuter des commandes arbitraires dans un contexte CI via une configuration contrôlée par l’utilisateur. La leçon dépasse GitLab : un agent d’IA branché sur le CI est une nouvelle surface d’exécution, et la configuration qu’il consomme fait désormais partie de la frontière de sécurité.

La version 3.18 du CI/CD auto-hébergé Woodpecker impose une migration de base qui touche le stockage des journaux — sauvegarde et fenêtre de maintenance recommandées avant de mettre à jour. Elle durcit aussi la sécurité : les variables d’environnement additionnelles et de matrice ne sont plus injectées automatiquement dans les plugins.

La version 0.39 de Docker Sandboxes, publiée le 19 août 2026, introduit des environnements déclaratifs décrits dans un fichier .sbxenv.yaml versionné et reproductibles via sbx env run. Les équipes qui exécutent des agents IA en CI doivent adopter ce format, mais verrouiller aussi la signature des kits et la gouvernance MCP.

CloudSEK chiffre le 11 août 2026 l’ampleur de la compromission de LiteLLM : 2 500 organisations et 434 000 pipelines CI/CD potentiellement exposés, via un build Trivy compromis qui a empoisonné les versions 1.82.7 et 1.82.8 sur PyPI. La leçon pour les équipes plateforme tient en trois décisions : épingler, scoper, et faire tourner le CI comme une surface d’attaque.

Le 5 août 2026, Novee Security a démontré à Black Hat USA qu’un simple ticket GitHub ouvert par un compte sans droit d’écriture permettait d’exécuter du code sur les runners CI des dépôts Claude Code, Gemini CLI et OpenAI Codex. Si vos pipelines CI/CD exécutent du code issu d’issues GitHub sans sandboxing, cet article est un ordre de patcher.

Docker a promu Buildx Bake en disponibilité générale avec Docker Desktop 4.38, supprimant le dernier obstacle au build multi-plateforme pour les équipes qui maintenaient encore des scripts séparés par architecture.