CRITICALCVSS 10.0EPSS 0.27CVE-2026-97229CI/CD
Votre GitLab mis à jour peut encore permettre une prise de contrôle totale du serveur
N'importe qui pouvant joindre un serveur GitLab auto-hébergé peut en prendre le contrôle avec un seul fichier de pipeline piégé, et des attaquants s'y essaient déjà.
GitLab a publié un correctif le 12 octobre. Le piège tient à l'endroit où se trouve la faille : pas dans le code de GitLab, mais dans Ruby, le langage dans lequel GitLab est écrit, et le correctif n'est livré que dans les paquets officiels de GitLab. Un serveur qui fait tourner GitLab sur sa propre copie de Ruby reste vulnérable après la mise à jour, tant que Ruby n'est pas mis à jour lui aussi. La CISA, l'agence de cybersécurité du gouvernement américain, a confirmé le 29 octobre que la faille est utilisée dans des attaques.
Alpine Linux l'a appris sur son propre serveur. Les 20 et 21 octobre, un attaquant avec un compte tout juste créé a envoyé des configurations CI piégées à gitlab.alpinelinux.org, a fait planter ses workers 8 fois et a mené l'exploit à mi-chemin 4 fois. Alpine est passé à 19.3.6 le 22 octobre et a découvert le 26 octobre qu'il était toujours vulnérable, parce que son image utilisait le Ruby standard. Alpine n'a trouvé aucune preuve que le code de l'attaquant ait tourné, sans pouvoir l'exclure, et a reconstruit le serveur de zéro : chaque mot de passe, chaque double authentification, chaque jeton d'accès et chaque valeur de variable CI/CD a été réinitialisé.
Sources : avis de GitLab, 12 oct. · avis de Ruby, 23 oct. · rapport d'incident d'Alpine, 28 oct. · CISA KEV, 29 oct. · Corrigé en 19.4.2, 12 oct.
#Aussi cette semaine
CRITICALCVSS 9.8EPSS 0.99CVE-2026-109618CVE-2026-109619PHP
Deux failles PHP exploitées permettent d'exécuter du code sans authentification
PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiés le 21 octobre, corrigent deux failles qui, selon l'équipe PHP, permettent une exécution de code à distance sans authentification : de la mémoire de requête laissée non initialisée après un arrêt pour manque de mémoire (CVE-2026-109618), et un état global qui pointe encore vers de la mémoire de requête libérée (CVE-2026-109619). La CISA a ajouté les deux à sa liste des failles exploitées le 26 octobre. Sa fiche pour la faille du noyau Linux CVE-2026-46300, ajoutée le 28 octobre, indique que les trois sont enchaînées pour implanter des webshells PHP et exécuter des commandes en root. Le NVD note la paire 9.8 et 8.1 ; PHP note les deux 9.2 en CVSS 4.0.
- [ ]Mettez PHP à jour vers la dernière version de votre branche, ou installez le paquet corrigé de votre distribution
- [ ]Mettez à jour le noyau Linux sur les mêmes serveurs
Sources : annonces de version de PHP, 21 oct. · CISA KEV, 26 et 28 oct. · Corrigé en 8.5.12, 21 oct.
INFOCHAÎNE D'APPROVISIONNEMENT
Une version piégée de LiteLLM a volé des identifiants pendant moins de deux heures
Le 21 octobre, le pipeline de publication de LiteLLM a publié litellm==1.107.0 sur PyPI de 11 h 39 à 13 h 23 UTC, et a fait pointer les tags d'image v1.107.0, latest, main-latest et main-stable sur Docker Hub et GHCR vers des images compromises de 11 h 46 UTC jusqu'à 14 h 20 UTC au plus tard. Cette version contenait un logiciel malveillant compilé qui vole des identifiants et charge des outils d'exécution de code à distance ; le tag source, lui, est sain. LiteLLM explique que l'attaquant détenait les jetons GitHub CLI de trois développeurs, a utilisé le jeton d'un propriétaire de l'organisation pour désactiver la protection de branche, et a redirigé le workflow de publication vers un dépôt imitant l'original. Il n'y a pas de score CVSS, car il s'agit d'une version compromise et non d'une faille dans le code : l'étiquette indique donc INFO.
# Ne lancez pas Python sur une machine suspecte :
# cook.pth s'exécute en premier
$ find / -path '*-packages/*' \( -name cook.pth \
-o -name cook.py -o -name sitecustomize.py \) 2>/dev/null
$ ls -l /tmp/remote_code_loader.lock
- [ ]Si une machine a un jour installé
1.107.0, considérez-la comme compromise : reconstruisez-la et changez chaque clé et chaque mot de passe qu'elle contenait - [ ]Bloquez LiteLLM en
1.106.2 jusqu'à nouvel avis du projet
Sources : rapport d'incident de LiteLLM, 21 oct., mis à jour le 30 oct.