En bref
Que s'est-il passé ?
Le 22 mai 2026, un acteur unique compromet quatre paquets Composer de l'organisation Laravel-Lang, dont le paquet phare laravel-lang/lang (502 tags), via un unique identifiant à accès push sur toute l'organisation.
Plutôt que publier une version malveillante, l'attaquant réécrit chaque tag git existant pour le faire pointer vers un commit piégé. Les commits ajoutent src/helpers.php à l'autoload.files de Composer : un simple require de vendor/autoload.php, exécuté au démarrage de toute appli Laravel ou Symfony, déclenche la charge.
La charge contacte flipboxstudio.info, dépose un loader PHP et un binaire ELF dans /tmp, exfiltre l'environnement du runner, puis efface ses propres artefacts pour gêner l'analyse. L'exploitation a été confirmée en détonant http-statuses v3.4.5 sous Harden-Runner.
Épingler dépendances et actions par SHA de commit (jamais par tag), interdire la réécriture de tags sur les dépôts sensibles, imposer la 2FA et durcir les comptes mainteneurs, détecter les mouvements de tags anormaux.
Chronologie de l'attaque
À 22h32 UTC, l'attaquant commence à réécrire les tags de laravel-lang/lang (502 tags).
Vers minuit UTC, les quatre dépôts (jusqu'à laravel-lang/actions) ont tous leurs tags réécrits.
StepSecurity confirme l'exploitation en détonant http-statuses v3.4.5 et ouvre une issue de sécurité dans les quatre dépôts.
Comment l'attaquant a procédé
Cet incident met en jeu les vecteurs d'attaque suivants du catalogue SOCLE ; chacun renvoie à sa fiche, où l'on trouve les exigences qui le neutralisent :
La leçon à en tirer
Pas de secrets en clair ; scan de secrets ; rotation et détection de fuite ; jetons courts.
Les exigences SOCLE qui auraient limité cet incident
Cet incident se rattache à 20 exigences du référentiel, par domaine. Les satisfaire n'aurait pas forcément tout empêché, mais aurait réduit la probabilité de l'attaque, limité son impact ou accéléré sa détection :