Attaque de la chaîne d'approvisionnement PHP : plus de 700 versions des paquets Laravel-Lang compromises par un malware

Le 22 mai 2026, des chercheurs d'Aikido Security, Socket et StepSecurity ont découvert une attaque sophistiquée contre l'écosystème PHP : quatre paquets du projet laravel-lang ont été backdoorisés avec un malware de vol de données qui s'exécute automatiquement dès l'installation du paquet via Composer.

Ce qui s'est passé

Les attaquants ont obtenu l'accès aux dépôts GitHub grâce à un GitHub Personal Access Token (PAT) divulgué, probablement issu d'une fuite antérieure sur GitHub. Avec cet accès, ils ont réécrit toutes les étiquettes (tags) de version existantes dans quatre dépôts du projet laravel-lang, les redirigeant vers des commits malveillants dans un fork qu'ils contrôlaient. Cela a compromis 233 versions directes et affecté environ 700 versions historiques.

La technique est particulièrement dangereuse car GitHub autorise les tags à référencer des commits provenant d'un fork du même dépôt. Tout développeur exécutant composer require ou composer update reçoit du code malveillant même si le nom du paquet et le numéro de version semblent parfaitement légitimes.

Paquets affectés

laravel-lang/lang — bibliothèque principale de localisation pour Laravel (7 800+ étoiles GitHub)
laravel-lang/http-statuses — traductions des codes d'état HTTP
laravel-lang/attributes — traductions des attributs Eloquent
laravel-lang/actions — traductions des actions courantes

Mécanisme de l'attaque

Le vecteur d'infection initial était un fichier src/helpers.php injecté dans le composer.json du paquet sous la clé autoload.files. Cela provoque l'exécution du code malveillant à chaque requête PHP dès l'installation du paquet, sans aucune action supplémentaire du développeur.

Le dropper (Phase 1) effectue un fingerprint du système via les chemins de fichiers, le hostname et les inodes, écrit un marqueur de persistance dans le répertoire temporaire, et obscurcit le domaine C2 dans des tableaux d'entiers avant de contacter l'infrastructure de l'attaquant. Sur Windows, il dépose un lanceur .vbs ; sur Linux/macOS, il utilise exec() pour une exécution en arrière-plan.

Analyse du payload

Le voleur de Phase 2 contient environ 5 900 lignes de code PHP réparties en 15 modules de collecte spécialisés. Ses capacités comprennent :

Clés cloud : AWS, GCP, Azure, tokens Kubernetes, Vault
Identifiants de dépôts : SSH, Git, GitHub, GitLab, Bitbucket
Données CI/CD : variables d'environnement, tokens de pipelines
Plus de 17 types de navigateurs (Chrome, Firefox, Brave, Edge, etc.)
Portefeuilles de cryptomonnaies : Bitcoin, Ethereum, Monero
Gestionnaires de mots de passe
Plateformes de communication : Slack, Discord
Fichiers .env, tokens API Stripe, PayPal et services similaires
Configurations VPN et clés SSH

Toutes les données exfiltrées sont chiffrées avec AES-256 avant transmission au serveur C2 (flipboxstudio[.]info, points de terminaison /payload et /exfil). Le malware se supprime ensuite lui-même pour entraver l'analyse forensique.

Chronologie

22 mai 2026 — 22:32 UTC : Début de l'attaque contre laravel-lang/lang
23 mai 2026 — 00:00 UTC : Attaque complète ; laravel-lang/actions compromis
23 mai 2026 : Aikido Security, Socket et StepSecurity signalent l'incident à Packagist
23 mai 2026 : Packagist supprime les versions malveillantes et retire temporairement les paquets
25 mai 2026 : Mise à jour de l'advisory avec de nouvelles conclusions

Ce que vous devez faire maintenant

Considérer l'environnement comme compromis. Si vous avez installé ou mis à jour l'un des quatre paquets entre le 22 et le 23 mai, considérez que toutes les données d'accès accessibles depuis ce processus PHP ont été volées.
Renouveler toutes les données d'accès. Clés AWS/GCP/Azure, tokens GitHub/GitLab, tokens Stripe/PayPal, clés SSH, mots de passe de base de données et tous les secrets dans les fichiers .env.
Ne pas installer ces paquets tant que le projet laravel-lang n'a pas confirmé l'intégrité de ses dépôts.
Bloquer le domaine C2 : flipboxstudio[.]info au niveau du pare-feu, DNS et WAF.
Analyser les journaux d'accès pour détecter des connexions sortantes vers ce domaine depuis le 22 mai.
Auditer les permissions SCM et activer l'authentification matérielle (FIDO2) sur tous les comptes disposant d'un accès en écriture.
Reconstruire depuis des images propres les serveurs exécutant le code affecté.

Leçon pour les équipes PHP

Cette attaque illustre un risque fondamental du modèle de paquets moderne : faire confiance au nom d'un paquet et à son numéro de version ne suffit pas. Les équipes doivent utiliser le hash pinning dans composer.lock, vérifier l'intégrité des paquets avec des outils comme Socket ou Aikido, et auditer régulièrement les dépendances transitives de leurs projets Laravel.