Attaque chaîne d’approvisionnement Laravel-Lang du 23 mai 2026 : 700 versions backdoorées, voici le plan en 5 actions sous 48h pour les RSSI français
RSSI et consultant senior — WebGuard Agency
TL;DR
- Les 22 et 23 mai 2026, un attaquant a republié ~700 versions malveillantes sous tags historiques des paquets
laravel-lang/lang,laravel-lang/http-statuses,laravel-lang/attributesetlaravel-lang/actions. - Vecteur : les tags GitHub peuvent pointer sur des commits dans un fork. Le pirate a réécrit l’historique apparent des dépôts sans modifier le code visible sur la page principale.
- Payload : un fichier
helpers.phpchargé viaautoload.filesde Composer, qui télécharge un stealer cross-platform depuisflipboxstudio[.]info. Cibles : clés cloud, secrets Kubernetes, Vault, tokens CI/CD, SSH, fichiers.env, navigateurs, password managers, wallets crypto. - Packagist a retiré les versions, mais les caches Composer, runners CI/CD et conteneurs déjà construits restent exposés. Sources : The Hacker News et Bleeping Computer.
- Plan détaillé ci-dessous en 5 actions sous 48 heures pour les RSSI français soumis à NIS2.
— Le contexte : un week-end de l’Ascension transformé en cauchemar pour les équipes PHP
Vendredi 22 mai 2026 en fin de journée, un attaquant a commencé à republier des tags Git sur quatre dépôts populaires de l’écosystème Laravel : laravel-lang/lang (28 millions de téléchargements Packagist), laravel-lang/http-statuses, laravel-lang/attributes et laravel-lang/actions. Au total, environ 700 versions historiques ont été réécrites pour pointer sur des commits situés dans un fork malveillant du référentiel. Samedi 23 mai, les premières alertes sur The Hacker News et Bleeping Computer ont fait remonter l’incident.
Pour comprendre la portée de l’attaque, il faut saisir le mécanisme : sur GitHub, un tag est une simple référence vers un commit. Or, GitHub autorise un tag à pointer sur un commit qui se trouve dans un fork du dépôt. Si l’attaquant obtient un accès en écriture sur l’origine (compromission de compte mainteneur, OAuth, token volé), il peut faire pointer un tag historique v6.2.0 de 2022 vers son propre commit malveillant logé dans un fork, sans modifier le code visible sur la page principale du dépôt. Packagist, qui se base sur les tags pour servir les versions, distribue alors le code piraillé sans rien détecter.
Le timing n’est pas anodin : ce week-end de l’Ascension prolongé correspond au moment où la majorité des équipes DevOps françaises ont des effectifs réduits, et où les pipelines CI/CD continuent de tourner pour les builds de pré-production. Plusieurs clients que nous accompagnons ont vu des runners GitLab déclencher composer update samedi soir et récupérer une version backdoorée avant le nettoyage Packagist.
— Anatomie du payload : un stealer cross-platform à large spectre
Le code malveillant injecté prend la forme d’un fichier helpers.php ajouté au manifeste Composer via la directive autoload.files. Cette directive force le chargement du fichier à chaque exécution PHP qui inclut vendor/autoload.php, c’est-à-dire la quasi-totalité des applications Laravel : commandes Artisan, requêtes HTTP, jobs queue, tests automatisés, pipelines CI.
Lorsque le fichier s’exécute, il contacte flipboxstudio[.]info, télécharge la deuxième étape adaptée à l’OS (Windows, Linux, macOS), puis lance un stealer ciblant : clés d’accès AWS (~/.aws/credentials), tokens GCP (~/.config/gcloud/), service principals Azure, kubeconfig et secrets Kubernetes, tokens Vault et autres coffres HashiCorp, tokens GitHub/GitLab/CircleCI/Jenkins, clés SSH privées (~/.ssh/id_*), tous les fichiers .env trouvés par recherche récursive, cookies et sessions des navigateurs Chrome/Firefox/Edge/Safari, bases de password managers locaux (KeePass, Bitwarden offline), wallets crypto (Metamask, Phantom, Exodus).
L’exfiltration utilise des canaux HTTPS standards vers plusieurs sous-domaines de flipboxstudio[.]info. L’empreinte réseau est faible mais détectable : les requêtes sortantes vers ce domaine constituent la signature la plus fiable pour une investigation rétrospective sur 30 jours.
« Ce que cette attaque met en lumière, c’est l’illégalité de fait du modèle de confiance dans Composer et Packagist. Quand vous épinglez une version dans composer.json, vous faites confiance au tag. Or le tag n’est pas la signature du code, juste une référence mutable. Sur 47 audits supply chain PHP menés en 2025-2026, seuls 6 clients avaient activé la vérification stricte des hashes dans composer.lock. La leçon Laravel-Lang : verrouiller les hashes ne suffit plus, il faut surveiller les changements de hash sur des versions déjà installées. »
Henrik Lindstrom, RSSI et consultant senior — WebGuard Agency
— Plan en 5 actions sous 48 heures pour RSSI français NIS2
Action 1 (heures 0 à 6) : audit composer.lock sur toutes les flottes PHP. Lancer un script Ansible ou bash qui parcourt tous les dépôts internes, runners CI/CD, conteneurs Docker en production et images de base. Pour chaque composer.lock, extraire les entrées laravel-lang/* avec les champs source.reference et dist.shasum. Comparer aux hashes publiés par Packagist après nettoyage le 23 mai. Tout désaccord = isolation immédiate du runner concerné et investigation forensique.
Action 2 (heures 4 à 12) : rotation immédiate des tokens CI/CD et secrets Vault. Partir du principe que toute installation effectuée entre le 22 mai 18h UTC et le 23 mai 20h UTC est compromise. Roter dans cet ordre de priorité : tokens GitHub/GitLab d’automation, secrets HashiCorp Vault exposés aux jobs CI, clés SSH des runners auto-hébergés, clés d’accès AWS/GCP/Azure utilisées par les pipelines, mots de passe applicatifs en clair dans .env. Documenter chaque rotation pour le dossier d’incident NIS2.
Action 3 (heures 6 à 24) : inspection des logs sortants sur 30 jours vers flipboxstudio[.]info. Récupérer les logs DNS récursifs, les logs proxy sortant, les logs NetFlow et les logs CloudTrail/CloudWatch. Rechercher toute résolution DNS ou connexion HTTPS vers flipboxstudio[.]info et ses sous-domaines sur la fenêtre du 22 avril au 25 mai 2026. Même si l’attaque est récente, certaines variantes ont pu déjà circuler. Toute résolution positive déclenche un incident NIS2.
Action 4 (heures 12 à 36) : blocage egress firewall vers flipboxstudio[.]info. Ajouter des règles deny sur tous les firewalls sortants (cloud security groups, pare-feu périmétriques, proxies forward). Pour les flottes Kubernetes, déployer des NetworkPolicy ou Cilium policies bloquant le domaine et son IP. Ajouter une règle Suricata ou Snort dans le SOC pour alerter sur toute tentative future. Cette action ferme la fenêtre d’exfiltration même si une compromission persiste sur un runner non encore identifié.
Action 5 (heures 24 à 48) : notification AIPD et CNIL si exposition confirmée. Si l’action 3 révèle des résolutions positives, ou si l’action 1 montre des hashes incohérents sur une production manipulant des données personnelles, déclencher la notification ANSSI sous 24h (NIS2 article 23) et la notification CNIL sous 72h (article 33 RGPD). Documenter la chaîne : vecteur Laravel-Lang, période d’exposition, données potentiellement exfiltrées, mesures de remediation. Prévoir une AIPD complémentaire si l’exposition concerne des catégories particulières (santé, biométrie, etc.).
Besoin d’aide pour auditer votre flotte PHP-Composer ?
Notre équipe CERT intervient en moins de 4 heures sur audit supply chain Composer, rotation orchestrée des secrets, forensic des runners CI/CD et reporting NIS2/CNIL. 47 audits supply chain PHP réalisés en 2025-2026.
Contacter le CERT WebGuard →— Qui est exposé en France et quels secteurs prioritaires
L’écosystème Laravel est massivement adopté en France : startups SaaS B2B, ETI e-commerce, éditeurs logiciels du ministère de l’Intérieur historiquement, plateformes métier de banques de détail. laravel-lang/lang est installé par défaut sur la majorité des projets multilingues, ce qui élargit considérablement la surface d’exposition. Plus inquiétant : les paquets laravel-lang/attributes et laravel-lang/actions sont aussi présents dans de nombreuses dépendances transitives.
En priorité absolue : les entités NIS2 essentielles et importantes ayant une stack PHP, les fintech avec API exposées, les plateformes santé (HDS) avec composants Laravel, les acteurs e-commerce traitant cartes de paiement (PCI-DSS), les administrations utilisant des CMS PHP ou ERP métier développés en interne. Notre audit périmètre NIS2 et notre méthodologie supply chain apportent le cadre de remediation adapté.
À noter : les équipes d-open.org ont publié un complément côté développeurs avec un runbook Composer détaillé pour sécuriser les pipelines CI/CD post-incident. Pour les enjeux IA agentic et détection automatisée des dérives supply chain, Plug-Tech a publié une analyse complémentaire sur les agents IA de monitoring continu pour PME françaises.
« Le piège classique sur ce type d’incident, c’est de se focaliser sur le retrait de la dépendance et d’oublier la rotation. Sur deux clients français audités ce week-end, on a retiré le paquet en 30 minutes, mais les tokens CI/CD compromis donnaient encore accès aux registries Docker privés pendant 6 heures. Le stealer exécuté samedi peut continuer à produire des dégâts dimanche même après nettoyage Composer. La rotation est la priorité 1, pas le retrait. »
Henrik Lindstrom, RSSI et consultant senior — WebGuard Agency
— Ce qu’il faut surveiller dans les 30 prochains jours
28 mai 2026 : publication attendue par l’ANSSI d’un advisory CERT-FR avec les IoC complets (hashes, URLs C2, mutexes). 30 mai – 5 juin : premières détections post-incident sur les flottes auditées par les SOC managed, attendons-nous à voir émerger des cas où des tokens GitHub volés sont utilisés pour rebondir vers d’autres dépôts privés. 10 juin : probable variante par d’autres écosystèmes (npm, PyPI) imitant la méthode « tag fork detournement », GitHub n’a toujours pas annoncé de fix sur le mécanisme de validation des tags.
« Pour une ETI française typique avec 10 à 30 dépôts PHP en interne et 3 à 8 runners CI/CD, le coût complet d’une remediation Laravel-Lang correctement menée tourne autour de 4 à 7 jours-ingenieur. Le coût caché, c’est la rotation Vault propre : peu d’équipes ont rodé le runbook, donc la rotation prend deux fois plus de temps que prévu. Investissez 2 jours par an à faire des exercices de rotation à froid, vous diviserez par 3 votre temps de réponse sur ce type d’incident. »
Henrik Lindstrom, RSSI et consultant senior — WebGuard Agency
Pour aller plus loin sur la gouvernance supply chain et l’hygiène développeurs, consultez notre guide ANSSI hygiène informatique et notre approche ASM cybersécurité.
Audit supply chain PHP express en 48h
Notre forfait audit Laravel-Lang « 5 actions 48h » couvre composer.lock toutes flottes, rotation Vault assistée, analyse logs sortants 30j, blocage egress, reporting NIS2 et CNIL prêt-à-signer. Tarif fixe ETI : 12 K€ HT.
Demander un devis →— FAQ
Comment savoir si mon application Laravel a installé une version backdoorée de laravel-lang ?
Inspecter composer.lock pour les packages laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes et laravel-lang/actions. Comparer les hashes source.reference avec ceux republiés par Packagist après le nettoyage du 23 mai 2026. Auditer la présence d’un fichier helpers.php chargé via autoload.files dans vendor/laravel-lang/. Vérifier les logs sortants des 30 derniers jours vers le domaine flipboxstudio[.]info qui sert de C2 stealer.
Quelles données ont pu être exfiltrées si le stealer s’est exécuté ?
Le payload est un stealer cross-platform Windows, Linux, macOS qui cible : clés cloud (AWS, GCP, Azure), secrets Kubernetes (kubeconfig, secrets API), tokens Vault et HashiCorp, tokens CI/CD (GitHub, GitLab, CircleCI, Jenkins), clés SSH privées, fichiers .env de projets, données navigateurs (cookies, sessions, mots de passe), password managers locaux, wallets crypto. L’exposition couvre largement la chaîne de développement et la production.
Pourquoi cette attaque a-t-elle pu passer sous le radar de Packagist ?
L’attaquant a exploité une faiblesse architecturale de GitHub : les tags d’un dépôt peuvent pointer sur des commits situés dans un fork du repository. En republiant 700 tags historiques pointant vers un fork malveillant, l’attaquant a contourné l’intégrité implicite que Composer et Packagist accordaient aux tags. Packagist a retiré les versions infectées après signalement, mais les CI/CD avec cache composer pouvaient déjà avoir installé les payloads.
Quelle obligation NIS2 et CNIL en cas d’exposition confirmée ?
Sous NIS2, l’entité essentielle ou importante doit notifier l’ANSSI dans les 24 heures suivant la détection d’un incident significatif, puis un rapport intermédiaire sous 72 heures et un rapport final sous un mois. Côté CNIL, toute violation de données personnelles impliquant un risque pour les droits doit être notifiée sous 72 heures (article 33 RGPD). Si secrets ou clés cloud d’accès à des données clients ont pu être exfiltrés, déclencher AIPD et notification CNIL en parallèle du reporting NIS2.