Alerte sur la chaîne d’approvisionnement de Laravel Lang

Attaque de la chaîne d’approvisionnement Laravel-Lang : plus de 700 anciennes versions Packagist compromises

Mise à jour — 25 mai 2026 : Nous avons actualisé cet article à la lumière des nouvelles conclusions de l’enquête en cours. Cette mise à jour précise le mécanisme de compromission, remplace les références précédentes à une publication via fork et ajoute des conseils aux utilisateurs de Composer/Packagist pour déterminer si un projet a été affecté. Comme les numéros de version concernés ont ensuite été réassociés à du code légitime, les numéros de version seuls ne suffisent pas toujours à confirmer l’impact. Les clients Snyk sont invités à consulter la section « Détecter l’attaque de la chaîne d’approvisionnement Laravel Lang avec Snyk » pour obtenir des conseils actualisés sur l’analyse, le triage et la correction.

En bref

Les 22 et 23 mai 2026, un attaquant a republié des centaines de versions malveillantes sous des balises de publication historiques pour quatre bibliothèques de localisation Laravel maintenues par la communauté et publiées sur Packagist sous l’espace de noms laravel-lang.

Un fichier helpers.php injecté a été ajouté à l’entrée autoload.files de Composer, ce qui le faisait s’exécuter à chaque requête PHP dès l’installation du package. Ce mécanisme contacte flipboxstudio[.]info, télécharge une seconde étape multiplateforme et exécute un voleur d’identifiants qui collecte des clés cloud, des secrets Kubernetes et Vault, des jetons CI/CD, des données SSH, des fichiers d’environnement, des données de navigateur, des coffres-forts de gestionnaires de mots de passe, des portefeuilles crypto et des jetons de messagerie.

Tout environnement ayant récupéré l’une des versions concernées de la bibliothèque de localisation Laravel doit être considéré comme compromis jusqu’à preuve du contraire.

À propos du composant concerné

Les packages concernés se trouvent sous l’espace de noms laravel-lang/* sur Packagist et GitHub.

La communauté Laravel les utilise largement pour distribuer des chaînes de traduction, des messages de validation, des descriptions de codes d’état HTTP et d’autres ressources localisées dans plus de soixante-dix langues.

L’équipe principale de Laravel ne les maintient pas et ils ne font pas partie du framework Laravel officiel, même s’ils sont installés dans le répertoire habituel des applications Laravel et apparaissent souvent comme dépendances transitives d’autres outils de localisation. Comme ces packages sont récupérés via Composer et enregistrés dans composer.json, tout code malveillant qu’ils contiennent est automatiquement chargé et exécuté par l’application.

Packages concernés

Toutes les versions publiées des quatre packages suivants ont été considérées comme compromises. Packagist les a temporairement retirés de son index, mais ils y figurent de nouveau après correction.

Les premières estimations des chercheurs faisaient état d’environ 233 versions piégées, mais ce nombre a augmenté à mesure que l’attaquant continuait à publier des balises. Les informations disponibles indiquent désormais environ 700 versions historiques pour les quatre packages.

Chronologie connue

Déroulement de la compromission

L’attaquant a accédé aux dépôts compromis grâce à un jeton d’accès personnel GitHub (PAT) divulgué, qui serait lié à une récente fuite de données GitHub. À l’aide de cet accès, l’attaquant a remplacé de nombreuses balises de publication, voire toutes, dans quatre dépôts laravel-lang/ par des copies malveillantes pointant vers ses propres commits contenant un logiciel malveillant. Les autres dépôts légitimes, y compris tous les commits précédents, sont restés en place pendant toute la compromission.

Dès qu’une balise malveillante était en place, toute nouvelle installation Composer résolvant l’une des versions concernées récupérait le code du commit usurpé. La charge utile était dissimulée dans un nouveau fichier, src/helpers.php, et déclaré dans composer.json sous autoload.files. L’autoloader de Composer inclut systématiquement chaque fichier de cette liste : le code malveillant s’exécute donc dès le début du cycle de vie de la requête PHP, notamment lors de commandes, de tâches en arrière-plan et de gestionnaires de files d’attente.

Comportement de la charge utile

La première étape, intégrée à src/helpers.php, est volontairement légère. Elle écrit un marqueur d’infection dans un répertoire temporaire propre à l’hôte afin de ne l’infecter qu’une seule fois, puis récupère une seconde étape depuis https://flipboxstudio\[.\]info/payload et l’exécute en arrière-plan. Le lanceur s’adapte à la plateforme et fonctionne sous Linux, macOS et Windows.

La seconde étape est un voleur d’identifiants et de secrets. Une fois installé, il parcourt de nombreuses sources à la recherche de données exploitables :

• Identifiants et jetons de fournisseurs cloud (par exemple, fichiers de profils AWS, GCP et Azure).

• Fichiers kubeconfig Kubernetes, jetons HashiCorp Vault et secrets CI/CD présents dans l’environnement.

• Clés privées SSH et données known_hosts.

• Fichiers .env d’application contenant des identifiants de base de données, d’API et de services.

• Données de navigateur, notamment cookies, historique et identifiants enregistrés.

• Coffres-forts de gestionnaires de mots de passe accessibles sur le disque.

• Fichiers et keystores de portefeuilles de cryptomonnaies.

• Jetons de messagerie et de collaboration pour des outils comme Slack, Discord et Telegram.

Les données collectées sont chiffrées puis envoyées à https://flipboxstudio\[.\]info/exfil. Après l’exfiltration, le voleur tente de supprimer les fichiers qu’il a déposés afin de compliquer l’analyse forensique. Sur les hôtes Windows, la chaîne comprend un script lanceur .vbs et un exécutable nommé DebugChromium.exe, observé sur des systèmes infectés.

Indicateurs de compromission

Utilisez les indicateurs suivants pour rechercher les systèmes concernés. Le domaine C2 et les URL doivent être considérés comme malveillants.

Conseils de détection et d’analyse

Considérez comme suspect tout hôte ayant résolu l’un des quatre packages entre le 22 et le 23 mai 2026, même s’il a été reconstruit depuis. Le signal le plus rapide se trouve au niveau des dépendances : examinez composer.lock et composer.json dans tous vos projets pour repérer les références aux packages laravel-lang listés ci-dessus. Voici quelques vérifications pratiques.

• Recherchez dans les artefacts de build et de déploiement laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes ou laravel-lang/actions, puis consignez la version et le hachage d’intégrité indiqués dans composer.lock.

• Examinez toute copie installée sous vendor/laravel-lang/*/ afin de repérer la présence de src/helpers.php et vérifiez si composer.json le déclare sous la clé autoload files. Un package de localisation légitime n’a aucune raison de fournir un fichier helpers chargé automatiquement à chaque requête.

• Sur les hôtes Linux et macOS, recherchez un répertoire .laravel_locale dans $TMPDIR et /tmp : la présence de contenu indique qu’il y a eu exécution. Copiez ces fichiers avant le nettoyage pour l’analyse forensique.

• Sur les hôtes Windows, recherchez dans le répertoire temporaire de l’utilisateur (généralement %TEMP%) un dossier .laravel_locale contenant des fichiers de dépôt .vbs dont le nom comporte huit caractères hexadécimaux aléatoires. Analysez séparément le système de fichiers pour repérer tout exécutable nommé DebugChromium.exe.

• Consultez les journaux de proxy de sortie, DNS et pare-feu pour repérer toute résolution ou connexion vers flipboxstudio[.]info. Bloquez le domaine au niveau du résolveur et du périmètre réseau.

• Dans les journaux EDR et des terminaux, recherchez les exécutions inattendues de processus PHP ou CScript en arrière-plan. Sous Linux et macOS, surveillez également les lectures dans /var/run/secrets/ et `/proc/[pid]/environ`, auxquels le voleur d’identifiants accède pour collecter des secrets.

Précisions sur les consignes d’exclusion

En raison de la nature de la compromission et des corrections apportées par la suite, les systèmes Snyk peuvent actuellement ne reconnaître que la dernière version installée. Les clients doivent effectuer une analyse historique pour vérifier si le package malveillant a été installé entre le 22 et le 23 mai 2026, et ne pas se fier uniquement à l’état de la dernière version. Partez du principe que tout hôte ayant installé l’un des quatre packages pendant la période de compromission est concerné, jusqu’à preuve du contraire.

Détecter l’attaque de la chaîne d’approvisionnement Laravel Lang avec Snyk

Pour les utilisateurs de Snyk, le produit Open Source et la Snyk Vulnerability Database signalent déjà toutes les versions des packages concernés. Pendant la compromission, des balises malveillantes ont été publiées sous des numéros de version légitimes. Lorsque les projets ont été rétablis, ces mêmes balises légitimes ont été dissociées des commits malveillants : les numéros de version seuls ne permettent donc pas de déterminer si un package installé a été ou est concerné par cette compromission. (Voir les sections Indicateurs de compromission et Conseils de détection et d’analyse ci-dessus.) Lancez immédiatement une analyse de tous les dépôts reposant sur Composer et portez une attention particulière aux monorepos et au code partagé de la plateforme.

Si, après avoir examiné votre composer.lock, les dates de build ou d’installation et les indicateurs de compromission disponibles, vous déterminez que votre projet n’a pas été affecté, vous pouvez utiliser la fonctionnalité Ignore de Snyk pour que ce problème n’apparaisse plus dans les analyses futures. Consultez la documentation Snyk sur l’ignorance des problèmes pour en savoir plus.

La CLI Snyk détecte automatiquement votre fichier de verrouillage Composer ainsi que les packages vulnérables et malveillants :

1snyk test

La CLI Snyk est gratuite. Si vous ne l’avez pas encore installée, consultez la documentation utilisateur de la CLI Snyk.

Si vous connectez Snyk à vos dépôts Git, Snyk peut ouvrir automatiquement des PR pour mettre à jour les packages vulnérables de votre fichier composer.lock vers des versions sécurisées.

Pour les clients Snyk Enterprise, nous avons déjà relancé les analyses pour vous. Consultez Analytics → Reports → Zero-Day → Active Security Incident Assessment pour l’attaque de la chaîne d’approvisionnement Laravel-Lang.

Atténuation et correction

Lorsque l’installation des packages concernés est confirmée, partez du principe que tout ce qui était lisible par le processus PHP au moment de l’exécution a été exfiltré, et agissez en conséquence. L’ordre ci-dessous correspond à la séquence habituelle de réponse aux incidents.

• Mettez en quarantaine les hôtes concernés. Retirez du trafic les services accessibles depuis Internet qui ont exécuté les versions touchées, créez des instantanés des disques à des fins d’analyse forensique et reconstruisez les systèmes à partir d’une image dont l’intégrité est connue, plutôt que de les nettoyer sur place.

• Veillez à ne pas récupérer les packages Laravel Lang concernés (ni, probablement, d’autres packages de ce mainteneur ou de cette équipe). L’attaquant ayant réécrit les tags Git historiques, aucun numéro de version publié ne peut être considéré comme fiable à lui seul : un numéro de version plus ancien peut désormais pointer vers le commit malveillant.

• Faites tourner tous les identifiants auxquels le processus PHP a pu accéder. Cela comprend les clés de fournisseurs cloud, les mots de passe de bases de données, les identifiants de files d’attente et de cache, les jetons d’API tierces, les secrets de clients OAuth, les clés SSH, les clés de signature, les jetons Vault et Kubernetes, ainsi que tous les secrets injectés par la CI/CD.

• Auditez les comptes des personnes qui partagent les mêmes postes de travail. Les identifiants enregistrés dans les navigateurs, les coffres-forts des gestionnaires de mots de passe, les portefeuilles crypto et les jetons Slack ou Discord ont également pu être volés. Changez les mots de passe enregistrés dans les navigateurs, invalidez les sessions et vérifiez les inscriptions à l’authentification multifacteur.

• Bloquez le domaine C2. Ajoutez flipboxstudio[.]info aux puits DNS, aux listes de blocage des proxys et aux règles de détection EDR. Une seule tentative de résolution constitue déjà un indice fort d’exposition.

• Vérifiez les autorisations SCM et de registre : laravel-lang/* a pu être récupéré de manière transitive. Assurez-vous que vos organisations GitHub, GitLab et Packagist disposent de l’authentification multifacteur reposant sur du matériel, de jetons aux autorisations limitées et d’une étape de validation pour la création de tags et la publication de packages.

Leçons tirées et défense en profondeur

Cet incident rappelle utilement que la limite de confiance d’un package ne se situe pas dans le dépôt source affiché dans l’onglet de votre navigateur. Elle englobe toute la chaîne de systèmes qui détermine quel commit devient un artefact publié. Quelques pratiques peuvent réduire l’ampleur des dégâts lors d’attaques similaires :

• Vérifiez l’intégrité lors de l’installation. Composer consigne les hachages du contenu des packages dans composer.lock ; utilisez --no-cache et la vérification de l’intégrité dans votre CI pour rendre toute altération détectable.

• Mettez en place des contrôles du trafic sortant dans les environnements de build. Les runners CI et les conteneurs de production ne devraient pas pouvoir accéder à des domaines arbitraires. Dans ce cas, une liste d’autorisation aurait empêché le téléchargement de la seconde étape.

• Utilisez des secrets à durée de vie limitée et aux autorisations restreintes. Des identifiants à longue durée de vie dans des fichiers .env amplifient les dégâts causés par tout vol de secrets en cours d’exécution.

La déclaration officielle du projet concerné, qui mentionne notamment GitHub, est disponible ici : Déclaration officielle sur l’incident.

Nous vous recommandons également de revoir vos pratiques de sécurité et de découvrir comment sécuriser le framework PHP Laravel dans un article que nous avons publié précédemment, ainsi que la ressource Snyk Learn sur les pratiques de développement PHP sécurisé.

État de Snyk

Les produits et l’infrastructure de Snyk ne sont pas concernés par cet incident. Les avis Snyk concernant les packages touchés ont été publiés, et la Snyk Vulnerability Database est mise à jour à mesure que de nouvelles plages de versions sont confirmées. Snyk continue de suivre la situation et révisera cet avis à mesure que de nouveaux éléments seront disponibles.