Laravel-Lang supply chain : 700 versions PHP backdoorées

Les faits

Le 22 mai 2026, les chercheurs d'Aikido Security ont détecté une attaque de supply chain ciblant quatre packages PHP du projet Laravel-Lang, l'une des bibliothèques de localisation les plus utilisées dans l'écosystème Laravel avec plusieurs dizaines de millions de téléchargements cumulés sur Packagist. Les packages concernés sont laravel-lang/lang, laravel-lang/attributes, laravel-lang/http-statuses et laravel-lang/actions. En moins de 24 heures, l'attaquant a distribué plus de 700 versions malveillantes, ce qui constitue l'une des attaques de supply chain PHP les plus massives de 2026.

Le vecteur d'attaque exploite une fonctionnalité légitime de GitHub. La plateforme permet à des tags de dépôts de pointer vers des commits appartenant à des forks du même dépôt. L'attaquant a créé un fork malveillant de chacun des quatre dépôts Laravel-Lang, y a injecté le code malveillant, puis a publié sur les dépôts originaux des centaines de tags — en mode automatisé selon la cadence observée — pointant vers ces commits infectés dans le fork contrôlé. Résultat : lorsqu'un développeur ou un pipeline CI/CD installe une version via Packagist, il reçoit le code du fork malveillant sans aucun indicateur visuel dans l'interface GitHub du dépôt officiel.

La technique d'injection du payload est chirurgicale. L'attaquant a ajouté un fichier src/helpers.php dans la section autoload.files du composer.json de chaque package compromis. Cette section est automatiquement incluse par Composer lors de la génération de l'autoloader, sans qu'aucun appel de fonction soit nécessaire. Le payload s'exécute dès que l'application appelle require __DIR__.'/vendor/autoload.php' — ce qui survient au démarrage de toute application PHP utilisant Composer. Laravel, Symfony, PHPUnit et la quasi-totalité des applications PHP modernes effectuent cet appel. Aucune instantiation de classe, aucun appel de méthode, aucun déclencheur spécial : le simple fait de démarrer l'application suffit à exécuter le payload.

L'analyse technique du payload par Aikido Security, BleepingComputer et Snyk révèle un infostealer cross-platform sophistiqué. Pour contourner les outils d'analyse statique, l'attaquant encode l'URL du serveur de commande et contrôle (C2) sous forme d'un tableau d'entiers décodé dynamiquement à l'exécution. Le domaine C2 identifié est flipboxstudio[.]info. Les données exfiltrées comprennent les fichiers .env de l'application (identifiants de bases de données, clés API, secrets OAuth, tokens de services tiers), les données de navigateur du système hôte (cookies, historique, identifiants stockés), les coffres-forts de gestionnaires de mots de passe accessibles sur disque, les fichiers de wallets de cryptomonnaies et leurs keystores, ainsi que les tokens d'authentification de Slack, Discord et Telegram.

La chronologie de l'attaque : le 22 mai 2026 au matin, création automatisée des 700+ tags malveillants sur les quatre dépôts GitHub. Le 22 mai en soirée, détection par Aikido Security lors d'une analyse de routine des métadonnées Packagist. Le 23 mai au matin, signalement à Packagist et à l'équipe Laravel-Lang. Le 23 mai après-midi, suppression des versions malveillantes et délistage temporaire des quatre packages pour audit. Selon l'advisory Snyk, les packages ont été réhabilités après que l'équipe Laravel-Lang a audité ses accès GitHub et révoqué les permissions compromises.

La dangerosité particulière de cette attaque tient à la mécanique des pipelines CI/CD modernes. Dans un environnement de déploiement continu, un push de code déclenche automatiquement une installation Composer récupérant les dernières versions des dépendances. Le payload malveillant s'exécute alors sur le serveur de production sans intervention humaine et souvent sans monitoring des appels réseau sortants des workers de build. La fenêtre d'exposition de 22 heures environ entre la première publication malveillante et la mise hors ligne par Packagist laisse penser que de nombreux environnements de production ont été touchés.

La popularité des packages ciblés amplifie l'impact : laravel-lang/lang compte plusieurs dizaines de millions de téléchargements cumulés sur Packagist. L'attaque Laravel-Lang n'est pas isolée dans le contexte 2026 : npm, PyPI et RubyGems ont tous été ciblés par des attaques de supply chain similaires cette année, confirmant une tendance structurelle dans les stratégies offensives. Les attaquants ciblent désormais la chaîne d'approvisionnement logicielle comme point d'entrée préférentiel dans les organisations, sachant que les outils de détection y sont souvent moins matures que sur le périmètre réseau.

Impact et exposition

Tout environnement PHP ayant effectué une installation ou mise à jour de l'un des quatre packages entre le 22 mai 2026 au matin et le 23 mai 2026 en fin d'après-midi est potentiellement compromis. Le risque est maximal pour les environnements de production avec pipelines CI/CD automatisés et pour les développeurs ayant exécuté composer update pendant cette fenêtre. Un environnement de développement local compromis peut également avoir exposé des identifiants de production si les fichiers .env locaux pointaient vers des services de production réels.

Recommandations

• Audit du composer.lock : vérifier si les versions des quatre packages dans vos composer.lock ont été publiées entre le 22 et le 23 mai 2026 — si oui, considérer l'environnement comme potentiellement compromis
• Rotation immédiate des secrets : régénérer toutes les clés présentes dans les fichiers .env (APP_KEY, DB_PASSWORD, clés API, tokens OAuth) sur les environnements exposés
• Révocation des tokens : révoquer et régénérer les tokens Slack, Discord, Telegram, GitHub et tout service OAuth présent dans les variables d'environnement
• Vérification du C2 en logs réseau : rechercher toute connexion sortante vers flipboxstudio[.]info dans les journaux pare-feu et réseau des 22-23 mai 2026
• Mise à jour vers des versions saines : exécuter composer update laravel-lang/lang laravel-lang/attributes laravel-lang/http-statuses laravel-lang/actions
• Intégrer composer audit dans les CI/CD : ajouter composer audit comme étape obligatoire avant tout déploiement en production