Attaque supply chain : 700 packages Laravel-Lang compromis

Comment les attaquants ont empoisonné 700 versions en quelques heures

Le 22 mai 2026, les chercheurs d'Aikido Security ont détecté une campagne d'attaque ciblant l'écosystème Laravel-Lang, l'un des ensembles de packages PHP les plus utilisés au monde pour la gestion des traductions et de l'internationalisation dans les applications Laravel. En moins de 24 heures, 233 versions de packages ont été compromises, réparties sur plus de 700 dépôts GitHub. La vitesse d'exécution — des dizaines de versions publiées à quelques secondes d'intervalle — trahit une automatisation poussée et une préparation minutieuse de plusieurs semaines.

Le vecteur d'attaque exploite une subtilité méconnue du système de versionnement de Packagist, le registre officiel de packages PHP. Sur GitHub, une version de tag peut pointer non pas vers un commit du dépôt officiel, mais vers un commit situé dans un fork contrôlé par l'attaquant. C'est exactement la technique employée : l'acteur malveillant a d'abord créé des forks privés des dépôts Laravel-Lang légitimes, y a inséré du code malveillant, puis a publié des tags de version pointant vers ces commits frauduleux. Le code malveillant n'apparaissait donc jamais dans l'historique Git des dépôts officiels, ce qui le rendait pratiquement invisible pour un auditeur manuel ou un outil de détection classique.

Trois packages sont confirmés compromis : laravel-lang/http-statuses, laravel-lang/actions et laravel-lang/attributes. Ces packages cumulent des millions de téléchargements et sont intégrés dans des milliers de projets Laravel actifs à travers le monde. Lorsqu'un développeur exécute composer install ou composer update et télécharge l'une des versions malveillantes, l'autoloader de Composer charge automatiquement le fichier src/helpers.php injecté dans le package, sans que la moindre action supplémentaire soit nécessaire de la part de la victime. L'infection est donc entièrement transparente et silencieuse.

Ce fichier src/helpers.php est en réalité un stealer PHP sophistiqué de 5 900 lignes, structuré en quinze modules spécialisés. Son architecture modulaire lui permet de fonctionner aussi bien sur Linux, macOS que Windows, ce qui en fait une menace véritablement multiplateforme. Après avoir collecté l'intégralité des secrets accessibles sur la machine cible, il chiffre le tout en AES-256 et exfiltre les données vers le domaine flipboxstudio[.]info/exfil, avant de s'auto-supprimer du disque pour effacer les traces forensiques. L'ensemble du cycle — collecte, chiffrement, exfiltration, auto-destruction — s'exécute en quelques secondes.

Les données ciblées couvrent un spectre alarmant d'informations sensibles. Côté cloud, le stealer recherche les clés d'accès AWS (Access Key ID, Secret Access Key, Session Token), les credentials GCP (Application Default Credentials), les tokens Azure Active Directory, ainsi que les credentials des plateformes DigitalOcean, Heroku, Vercel, Netlify, Railway et Fly.io. Il collecte également tous les fichiers .env et fichiers de configuration présents sur la machine — une mine d'or dans les environnements de développement où les secrets de production se retrouvent fréquemment en clair.

Pour les pipelines CI/CD, le stealer cible les tokens GitHub (Personal Access Tokens, GitHub Actions secrets), GitLab, CircleCI, Travis CI et Jenkins. Les clés SSH stockées dans le répertoire ~/.ssh constituent une cible prioritaire, permettant potentiellement un accès direct aux serveurs de production. Au niveau des données personnelles, le stealer extrait les mots de passe sauvegardés depuis 17 navigateurs basés sur Chromium — Chrome, Brave, Edge, Opera et leurs variantes — et tente d'accéder aux bases de données des gestionnaires de mots de passe les plus répandus. Les portefeuilles de cryptomonnaies sont également ciblés, avec une recherche active des fichiers wallet Bitcoin, Ethereum et autres actifs numériques.

La détection a été rendue difficile par la combinaison de plusieurs facteurs : l'absence de code malveillant dans les dépôts officiels (le code frauduleux n'existant que dans les forks), la légitimité apparente des noms de packages, et la suppression automatique du payload après exécution. Selon Aikido Security, qui a signalé l'attaque à GitHub et à l'équipe Laravel-Lang dès la détection le 22 mai, les versions malveillantes ont été retirées dans les heures suivant la découverte. Packagist a également été notifié et les versions compromises ne sont plus disponibles via le registre officiel. Cependant, tout environnement de développement ou serveur CI/CD ayant exécuté une mise à jour Composer pendant la fenêtre d'exposition — du 22 au 23 mai 2026 — doit être considéré comme potentiellement compromis et traité en conséquence.

Selon CybersecurityNews, l'ampleur de l'attaque est sans précédent dans l'écosystème PHP : plus de 700 versions de release ont été créées automatiquement, ce qui suggère l'utilisation de scripts ou de tokens d'API GitHub compromis pour accélérer la publication des tags malveillants. L'enquête est toujours en cours pour identifier les auteurs et déterminer si d'autres packages de l'écosystème Composer ont été ciblés dans le cadre de la même campagne.

Pourquoi cette attaque redéfinit la menace supply chain dans l'écosystème PHP

L'écosystème PHP, et Laravel en particulier, représente une surface d'attaque considérable : Laravel propulse plusieurs millions d'applications web actives dans le monde, dont une proportion significative dans les secteurs du e-commerce, des services financiers et de la santé numérique. Une attaque réussie sur un package transversal comme ceux de Laravel-Lang peut théoriquement compromettre des dizaines de milliers d'environnements de production en une seule opération coordonnée, ce qui explique l'attrait croissant de ces vecteurs pour les groupes APT et les cybercriminels organisés.

Cette attaque s'inscrit dans une tendance lourde documentée depuis 2020 : les acteurs malveillants délaissent de plus en plus les attaques frontales sur les cibles finales pour s'en prendre aux outils et dépendances utilisés par les développeurs. Le rapport DevOps 2026 de Snyk recense 29 millions de secrets hardcodés dans des dépôts publics et souligne que les pipelines CI/CD constituent désormais la cible privilégiée des campagnes cherchant à établir un accès persistant dans les environnements d'entreprise. La compromission d'un seul package populaire peut offrir un accès en cascade à des centaines d'organisations.

Le précédent le plus comparable reste l'attaque contre le package npm event-stream en 2018, où un mainteneur malveillant avait injecté un payload ciblant les portefeuilles Bitcoin Copay dans un package téléchargé deux millions de fois par semaine. Mais l'attaque Laravel-Lang va plus loin en termes de sophistication technique : l'exploitation du mécanisme de tags GitHub pour éviter toute trace dans l'historique officiel représente un nouveau niveau de furtivité qui complique considérablement les audits de sécurité basés sur la revue de code. Cette technique de "tag hijacking" via les forks pourrait être réutilisée contre d'autres gestionnaires de packages utilisant GitHub comme backend — npm, PyPI, Cargo ou RubyGems.

Pour les équipes de sécurité, cet incident soulève des questions fondamentales sur la confiance accordée aux gestionnaires de packages. Composer, comme npm ou PyPI, résout les dépendances en se basant sur des métadonnées de version et des hashes cryptographiques — mais ces hashes garantissent uniquement l'intégrité du téléchargement, pas la légitimité du code source référencé par le tag. Les outils de Software Composition Analysis (SCA) traditionnels, qui se contentent de vérifier les CVE connus, sont aveugles face à ce type d'attaque qui n'exploite aucune vulnérabilité répertoriée mais détourne la confiance inhérente au système de publication. Une révision des processus d'audit et l'adoption de pratiques de vérification plus strictes s'imposent dans tout pipeline CI/CD exposé à des packages open source.

Ce qu'il faut retenir

• Si vous utilisez laravel-lang/http-statuses, laravel-lang/actions ou laravel-lang/attributes et avez exécuté composer update les 22-23 mai 2026, révoquez immédiatement tous vos secrets cloud, tokens GitHub et credentials CI/CD.
• Le vecteur d'attaque (tags GitHub pointant vers des forks malveillants) n'est pas détectable par simple revue du dépôt officiel — seule une comparaison des hashes du fichier composer.lock avec les releases officielles permet de confirmer l'intégrité.
• Adoptez des politiques de dépendances strictes : version pinning explicite, vérification systématique des hashes, alertes automatiques sur les nouvelles versions de packages critiques et revue obligatoire avant toute mise à jour en pipeline CI/CD.