Attaque Supply Chain sur Laravel-Lang : 233 packages empoisonnés en 15 minutes
Le 22 mai 2026, un attaquant a compromis en moins d'un quart d'heure 233 versions de packages PHP parmi les plus utilisés de l'écosystème Laravel. 700 dépôts GitHub ont été affectés, et tout développeur ayant exécuté un composer update ce jour-là a potentiellement exposé ses clés AWS, ses clés SSH, ses mots de passe de bases de données et ses fichiers de portefeuilles crypto. Aucune alarme ne s'est déclenchée. Aucune erreur n'a été levée. Les dépôts officiels GitHub semblaient parfaitement intacts.
Source originale : Someone Poisoned Laravel's Most Trusted Packages par Merradou Abderrahmane.
Ce qui s'est passé : une attaque invisible sur les tags Git
La subtilité de cette attaque réside dans son vecteur : les tags Git. L'attaquant n'a pas modifié le code source des dépôts officiels laravel-lang/http-statuses, laravel-lang/actions et laravel-lang/attributes. Il a réécrit les tags de version pour les faire pointer vers un fork malveillant.
Concrètement, lorsque Composer résout une dépendance, il se fie au tag Git associé à la version demandée. Si ce tag est déplacé vers un autre commit — même dans un fork externe — Composer télécharge silencieusement ce nouveau contenu sans avertissement. Le composer.lock peut même rester cohérent en apparence si le hash du tag a été recalculé côté attaquant.
Cette technique contourne les mécanismes de confiance habituels :
- L'historique des commits du dépôt officiel reste inchangé
- Aucune pull request suspecte n'est visible
- Les outils d'audit classiques ne détectent rien d'anormal
Ce que le malware exfiltrait
Le code injecté ciblait des données hautement sensibles présentes dans les environnements de développement et de production :
- Credentials cloud : clés d'accès AWS, tokens GCP/Azure
- Clés SSH : fichiers
~/.ssh/id_rsa, ~/.ssh/id_ed25519
- Mots de passe navigateur : bases de données des gestionnaires intégrés (Chrome, Firefox)
- Secrets CI/CD : variables d'environnement injectées dans les pipelines GitHub Actions, GitLab CI, etc.
- Portefeuilles crypto : fichiers de configuration de wallets locaux
L'exfiltration était silencieuse, sans erreur visible, intégrée dans le flux d'initialisation normal des packages.
Suis-je concerné ? Comment vérifier
Si votre projet utilise l'un de ces trois packages et que vos dépendances ont été mises à jour aux alentours du 22 mai 2026, considérez votre environnement comme compromis.
Vérification rapide dans votre projet :
grep -E "laravel-lang/(http-statuses|actions|attributes)" composer.lock
Si l'un de ces packages apparaît, vérifiez la date de votre dernier composer update ou composer install. En cas de doute, procédez immédiatement à la rotation de tous vos secrets.
Actions à mener sans délai :
- Révoquer et regénérer toutes les clés AWS / GCP / Azure
- Remplacer vos paires de clés SSH
- Changer les mots de passe de vos bases de données
- Invalider les tokens d'accès CI/CD (GitHub Actions secrets, GitLab CI variables)
- Auditer les logs d'accès à vos services cloud pour détecter toute activité anormale
Leçons pour sécuriser votre chaîne d'approvisionnement Composer
Cet incident illustre une réalité souvent sous-estimée : la surface d'attaque d'un projet PHP ne se limite pas à votre code. Chaque dépendance est un vecteur potentiel.
Épingler les versions par hash de commit
Plutôt que de se fier uniquement aux tags sémantiques, il est possible de référencer un commit précis dans composer.json :
"laravel-lang/http-statuses": "dev-main#a1b2c3d4e5f6"
Cela garantit que Composer télécharge exactement le contenu attendu, indépendamment des mouvements de tags.
Utiliser composer audit et des outils de vérification d'intégrité
Depuis Composer 2.4, la commande composer audit vérifie les vulnérabilités connues via la base de données Packagist Security Advisories. Intégrez-la dans vos pipelines CI :
- name: Audit des dépendances
run: composer audit
Activer la vérification des sommes de contrôle
Composer calcule et stocke les hashes des archives téléchargées. Assurez-vous que l'option secure-http est activée et que vous n'utilisez pas --no-verify.
Surveiller les mises à jour de dépendances en production
N'exécutez jamais composer update directement en production sans passer par un pipeline de validation. Toute mise à jour doit être auditée, testée et validée dans un environnement intermédiaire avant déploiement.
Mettre en place une politique de dépendances minimales
Chaque package ajouté est une surface d'attaque supplémentaire. Questionnez systématiquement la nécessité d'une dépendance avant de l'intégrer, et préférez les packages maintenus activement par des organisations reconnues.
Conclusion
Cette attaque sur l'écosystème Laravel-Lang est un rappel brutal que la sécurité d'une application web ne s'arrête pas à son code source. Les supply chain attacks ciblent précisément les angles morts de notre confiance implicite envers les outils et les dépôts que nous utilisons quotidiennement.
La réponse à ces menaces passe par une combinaison de vigilance opérationnelle, de durcissement des pipelines CI/CD et d'une culture de sécurité appliquée dès la gestion des dépendances. Chez MulerTech, nous intégrons systématiquement ces pratiques dans nos projets Symfony et PHP — parce qu'un environnement de confiance se construit dépendance par dépendance.
