Vendredi 22 mai 2026, vers 19h heure de Paris, les premières alertes Aikido, Snyk et Mend tombent presque simultanément. Quatre packages historiques de l’écosystème Laravel — laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses, laravel-lang/actions — distribuent des versions piégées via Packagist. En 36 heures, le compteur monte de 233 versions à plus de 700 versions historiques compromises. C’est l’une des attaques supply chain les plus larges visant l’écosystème PHP en 2026.
Le 23 mai au matin, j’ai imposé 5 actions à 18 projets PHP français que j’accompagne (PME, agences, freelances). Cet article décortique l’attaque, livre la méthode d’audit complète en 90 minutes par projet, et explique pourquoi les attaques de type tag-rewrite Composer vont se multiplier.
Anatomie de l’attaque tag-rewrite Composer
Le mécanisme de l’attaque exploite une faiblesse structurelle dans la chaîne Packagist → GitHub → Composer. Lorsqu’une version est publiée sur Packagist, le résolveur Composer va chercher le tag Git correspondant sur le dépôt GitHub déclaré. Si l’attaquant prend le contrôle du dépôt GitHub (compromission de compte mainteneur, accès via une PAT volée, social engineering), il peut réécrire les tags historiques pour pointer vers ses propres commits malveillants. Composer télécharge alors silencieusement la version piégée la prochaine fois qu’un dev fait composer update.
Sur Laravel-Lang, l’attaquant a injecté un fichier helpers.php minimaliste dans chaque version. Ce fichier était déclaré dans la section autoload.files du composer.json, ce qui signifie qu’il est exécuté automatiquement à chaque requête PHP, même sans appel explicite par l’application. C’est la signature d’une charge utile pensée pour une exfiltration en arrière-plan sans déclencher les WAF.
Le second stage téléchargé depuis flipboxstudio[.]info est un credential stealer multi-cible. Il scrape les clefs AWS/GCP/Azure, les configurations Kubernetes (~/.kube), les secrets HashiCorp Vault, les tokens GitHub Actions et GitLab CI, le matériel SSH (~/.ssh), tous les .env du système, les bases de données navigateur (cookies, mots de passe), les vaults 1Password/Bitwarden/LastPass, les wallets crypto (Metamask, Phantom, Ledger Live) et les tokens Slack/Discord.
💡 Notre avis d’expert
L’attaque Laravel-Lang n’est pas une nouveauté en termes de vecteur (tag-rewrite est connu depuis 2022), mais elle est inédite par sa scalabilité. 700 versions réécrites en 36 heures, c’est ~20 versions par heure. L’attaquant a clairement automatisé sa chaîne. C’est exactement ce qu’on craignait depuis l’affaire Nx en août 2025 : la barrière à l’entrée des attaques supply chain est désormais quasi nulle.
Les 5 actions à imposer immédiatement à tout projet PHP français
Action 1 — Audit composer.lock et vendor/ en moins de 10 minutes
Première chose à faire sur chaque projet : grep -r "laravel-lang" composer.lock pour identifier la version installée. Si elle a été installée entre le 21 et le 24 mai 2026, lancez immédiatement composer audit --locked (Composer 2.7+) qui croisera votre lock file avec la base d’avis de sécurité. Ensuite, vérifiez manuellement vendor/laravel-lang/*/helpers.php : recherchez les chaînes flipboxstudio, base64_decode, eval(, file_get_contents("http. Sur les 18 projets que j’ai audités, 2 étaient compromis directement et 4 via dépendance transitive (Filament Admin Panel utilise laravel-lang/lang en sub-dependency).
Action 2 — Rotation immédiate de tous les secrets exposés
Si une exécution PHP a eu lieu après le 21 mai sur un environnement contenant le package compromis, partez du principe que les secrets sont compromis. Rotation obligatoire : clefs AWS IAM et root, clefs GCP service accounts, secrets Azure, tokens GitHub PAT et GitHub Actions, tokens GitLab CI, clefs SSH déployées sur les serveurs, contenus .env (DB passwords, API keys tierces, JWT secrets), wallets crypto sur les postes dev. C’est la partie la plus pénible mais la plus critique. Plug-Tech et Webguard Agency publient une checklist de rotation à jour pour les PME françaises.
Action 3 — Durcir la CI : bloquer les builds sur signatures inconnues
La leçon stratégique de l’attaque : votre CI doit refuser de builder si Composer télécharge un package non audité. Trois mécanismes complémentaires : (1) verrouiller composer.lock par commit hash et non par tag (utiliser composer config preferred-install dist et croiser avec hash), (2) activer composer audit en obligatoire dans le pipeline, (3) ajouter Socket.dev ou Phylum en pre-install pour scanner toute nouvelle version. Sur GitHub Actions, ces 3 étapes prennent 12 lignes de YAML.
💡 Notre avis d’expert
Sur les 18 projets audités, 4 sur 18 avaient déjà composer audit en CI mais sans bloquer le build sur l’échec. C’est l’erreur classique : on logge sans bloquer. La règle d’or : si composer audit remonte un avis CVE ou suspect, le build doit échouer. Sinon vous payez le coût du contrôle sans en avoir le bénéfice.
Action 4 — Monitorer les résolutions DNS suspectes
Côté infrastructure, ajoutez flipboxstudio.info et ses sous-domaines connus à votre liste de domaines bloqués (DNS firewall, Pi-hole, Cloudflare Zero Trust). Sur vos serveurs PHP en production, analysez les journaux DNS des 14 derniers jours. Toute résolution vers ce domaine est un indicateur de compromission certain. Plus largement, abonnez-vous au flux IOC de l’ANSSI CERT-FR et de l’ENISA — la mise à jour CERTFR-2026-AVI-0418 documente cet incident.
Action 5 — Mettre en place une politique de dépendances PHP durcie
La leçon de fond : la chaîne Composer/Packagist/GitHub n’est pas conçue pour résister à des attaquants sophistiqués. Quatre mesures structurelles à intégrer dans votre charte tech : (1) proxy Packagist privé (JFrog Artifactory ou Sonatype Nexus) avec scan SCA systématique avant publication interne, (2) lockfile par commit hash, jamais par tag flottant, (3) SBOM CycloneDX généré à chaque build et archivé 24 mois, (4) upgrade hebdomadaire encadré avec revue manuelle des diffs de dépendances majeures. Sur cette dernière, je recommande la méthode Plug-Tech pour PME et ETI françaises.
Ce que l’attaque révèle sur la chaîne PHP française
Trois observations structurelles que cette affaire met en lumière, et que tout dev PHP français devrait avoir en tête en 2026.
1. La dépendance transitive est le maillon faible. Sur les 18 projets audités, 67 pourcent n’utilisaient pas laravel-lang en dépendance directe. Mais 22 pourcent l’avaient via Filament, Spatie, Lighthouse, ou Backpack. Le dev moyen ne fait pas l’audit récursif. Solutions : composer show --tree, SBOM systématique, et alerting sur les dépendances transitives via Socket.dev.
2. Le tag-rewrite est sous-monitoré. Contrairement aux compromissions npm (où la détection s’améliore vite via Snyk, GitHub Advisory Database, OSV), le tag-rewrite Composer reste sous-monitoré. Trois jours après la divulgation, la moitié des PME françaises que je suis n’avaient toujours pas reçu d’alerte automatique. C’est un angle mort à corriger.
3. La rotation de secrets est inopérante. Sur les 6 projets compromis (directs + transitifs), 5 n’avaient aucun playbook de rotation rapide. Il faut 4 à 12 heures pour faire tourner correctement secrets cloud + CI/CD + Vault + SSH. Sans playbook préparé, ce délai monte à 3 jours, ce qui laisse le temps à l’attaquant de pivoter.
L’attaque Laravel-Lang du 22 mai 2026 doit servir de signal d’alarme à toute la communauté PHP française. La chaîne Composer/Packagist n’a pas de défense intrinsèque contre le tag-rewrite. Les défenses doivent être au niveau de chaque projet : SCA, audit transitif, rotation prête. Pas de demi-mesure. — Julien Moreau, D-Open
Plan d’action court terme pour les devs PHP français
Voici la checklist exacte que j’ai distribuée aux 18 équipes auditées le 23 mai 2026. Faisable en 90 minutes par projet.
- Audit immédiat (10 min) :
grep laravel-lang composer.lock+composer audit --locked+ scan visuel devendor/laravel-lang/*/helpers.php. - Inventaire transitif (15 min) :
composer show --tree | grep laravel-langetcomposer show -t [package] | headpour les dépendances majeures (Filament, Spatie, Lighthouse, Backpack). - Rotation secrets (40 min) : clefs AWS/GCP, GitHub Actions tokens, GitLab CI tokens, SSH déployées, contenu
.env, wallets crypto si présents. - Durcissement CI (15 min) : ajout de
composer auditbloquant en pre-build, ajout de Socket.dev ou Phylum sur la PR. - Monitoring DNS (10 min) : blocage flipboxstudio.info et sous-domaines, scan journal DNS sur 14 jours, abonnement aux IOC ANSSI CERT-FR.
Si vous accompagnez des PME et avez besoin d’une équipe expérimentée, Plug-Tech propose un audit éclair PHP en 48 heures, et Webguard Agency couvre le périmètre cybersécurité full-stack avec un sprint de remédiation 14 jours.
FAQ : Laravel-Lang supply chain attack mai 2026
Qu’est-ce que l’attaque Laravel-Lang du 22 mai 2026 ?
Le 22 mai 2026, des chercheurs ont détecté qu’un attaquant avait réécrit les tags Git de 4 packages laravel-lang/* (lang, attributes, http-statuses, actions) en pointant vers des commits d’un fork malveillant. Composer ayant résolu les tags via GitHub, plus de 700 versions historiques distribuées via Packagist contenaient un helpers.php malveillant injecté dans autoload.files, exécuté à chaque requête PHP.
Quel est le payload final du credential stealer ?
Le helpers.php contacte flipboxstudio[.]info pour télécharger un second stage multi-plateforme. Ce stealer scrape les clefs cloud (AWS, GCP, Azure), les secrets Kubernetes et HashiCorp Vault, les tokens CI/CD (GitHub Actions, GitLab CI), le matériel SSH, les fichiers .env, les données navigateur, les vaults gestionnaires de mots de passe, les wallets crypto et les tokens messagerie.
Comment savoir si mon projet PHP a été compromis ?
Cinq signaux concrets : (1) composer.lock contient une version laravel-lang/* installée entre le 21 et le 23 mai 2026, (2) vendor/laravel-lang/*/helpers.php contient un appel à flipboxstudio[.]info ou un payload base64, (3) journaux DNS de votre serveur ou poste contenant des résolutions vers flipboxstudio.info, (4) processus inhabituels ou tâches cron créées le 22-23 mai, (5) accès récents non expliqués sur vos secrets cloud, CI/CD ou wallets crypto.
Comment se prémunir des attaques tag-rewrite Composer à l’avenir ?
Quatre mesures structurelles : (1) verrouiller composer.lock par commit hash et non par tag, (2) activer Composer Audit en CI et bloquer les builds sur signatures inconnues, (3) utiliser un proxy Packagist privé (JFrog Artifactory, Sonatype Nexus) avec scan SCA systématique, (4) monitorer Phylum, Socket.dev ou Sonatype Lifecycle pour les alertes supply chain en temps réel.
Votre projet PHP est-il à risque ?
D-Open accompagne les freelances et agences PHP françaises sur l’audit supply chain éclair. Sprint type 90 minutes par projet, rapport de remédiation à 48h. Voir notre guide audit Composer.
Discutons-en avec un expert D-Open