laravel-lang compromis : comprendre l'attaque et savoir si vous êtes touché

Le 22 mai 2026, une attaque de type supply chain visant trois packages très populaires de l'écosystème Laravel a été détectée.

En quelques heures, plus de 233 versions ont été retirées de Packagist : pendant ce temps, un simple composer install pouvait suffire à compromettre tout une machine.

Un détail rend cette attaque particulièrement intéressante : le code malveillant n'a jamais été poussé dans les repos officiels de laravel-lang et pourtant des milliers de développeurs ont pu télécharger une version malvaillantes du package.

Voyons comment cela a été possible.

• Ce qui s'est passé
• Les versions et packages impactés
• Comment savoir si vous êtes touché
• Ce qui a pu être volé
• Conclusion

Ce qui s'est passé

Pour comprendre l'attaque, il faut d'abord se rappeler comment Composer télécharge une version de package.

Lorsque vous exécutez un composer install, Composer interroge Packagist pour savoir où trouver la version demandée d'un package. Packagist lui répond avec une référence vers un tag GitHub et Composer télécharge alors l'archive ZIP correspondant à ce tag.

C'est là qu'intervient un détail important à l'origine de l'attaque : GitHub autorise un tag de version à pointer vers un commit présent dans un fork du repo et non uniquement vers un commit du repo officiel.

L'attaquant a exploité cette mécanique en trois étapes : forker les repos laravel-lang, ajouter son propre code malveillant dans son fork, puis créer dans les repos officiels des tags qui pointaient en réalité vers les commits du fork.

L'attaque est sournoise : l'historique du repo officiel reste propre, aucun commit suspect n'apparaît, mais l'archive ZIP que Composer télécharge contient bel et bien le code du fork compromis.

Les versions et packages impactés

Trois packages ont été touchés par cette attaque tous appartenant à l'organisation laravel-lang sur GitHub :

• laravel-lang/lang
• laravel-lang/attributes
• laravel-lang/http-statuses

Au total, 233 versions ont été identifiées comme compromises et retirées de Packagist dans la journée du 22 mai 2026.

Un point essentiel à comprendre : les numéros de version compromis sont identiques à des numéros de version légitimes existants, ce n'est pas le numéro qui change, c'est le commit derrière le tag !

Concrètement, un composer require laravel-lang/lang:^X.Y.Z ne révèlera rien de suspect dans votre composer.json ou votre composer.lock à la simple lecture du numéro de version : il faut regarder un peu plus loin.

Comment savoir si vous êtes touché

La détection se fait en trois temps : identifier la présence des packages, vérifier le hash du commit téléchargé puis chercher les traces laissées par le code malveillant sur la machine.

Première étape, lister les packages laravel-lang installés :

1composer show | grep laravel-lang

Si aucun des trois packages mentionnés plus haut n'apparaît, vous n'êtes pas concerné par l'attaque.

Deuxième étape, inspecter le composer.lock :

Pour chaque package laravel-lang installé, votre composer.lock contient un champ source.reference qui correspond au hash exact du commit téléchargé.

Ce hash est la véritable identité de ce que vous avez installé, indépendamment du numéro de version affiché.

1{
2    "name": "laravel-lang/lang",
3    "version": "X.Y.Z",
4    "source": {
5        "type": "git",
6        "url": "https://github.com/Laravel-Lang/lang.git",
7        "reference": "abc123..."
8    }
9}

Si ce hash ne correspond à aucun commit présent dans l'historique du repo officiel sur GitHub, vous avez installé une version compromise.

Vous pouvez le vérifier rapidement en collant le hash dans l'URL : https://github.com/Laravel-Lang/lang/commit/<hash>.

Un commit absent du repo officiel renverra une page d'erreur ou indiquera qu'il provient d'un fork.

Troisième étape, chercher les traces sur la machine :

Même si vous avez depuis mis à jour vers une version saine, le code malveillant a pu s'exécuter au moins une fois et laisser des traces sur le système, trois choses sont à vérifier :

• un fichier src/helpers.php dans vendor/laravel-lang/lang/, vendor/laravel-lang/attributes/ ou vendor/laravel-lang/http-statuses/
• un dossier .laravel_locale/ dans le répertoire temporaire du système (/tmp sur Linux/macOS, %TEMP% sur Windows)
• toute trace de trafic sortant vers le domaine flipboxstudio.info dans vos logs

Ce qui a pu être volé

Si le code malveillant s'est exécuté sur votre machine, le code téléchargé est un credential stealer, en français un "voleur d'identifiants".

Sans entrer dans une liste exhaustive (vous trouvez une liste complète sur l'article d'Aikido), considérez comme potentiellement compromis :

• Vos credentials cloud (AWS, GCP, Azure et autres)
• Vos clés SSH privées et tokens Git
• Tous les fichiers .env accessibles
• Les mots de passe enregistrés dans vos navigateurs

Si vous êtes concerné, considérez ces identifiants comme compromis et procédez à leur rotation sans délai.

Conclusion

Cette attaque nous rappelle que la confiance dans un package ne se limite pas à son repo source, elle s'étend à tout le chemin entre Packagist, GitHub et notre machine : un seul maillon faible dans cette chaîne suffit à compromettre l'ensemble.

Le composer.lock ne nous protège pas, il garantit seulement qu'une version reste figée ... pas que cette version reflète réellement ce qui se trouve dans le repo officiel.

Auditer ses dépendances, vérifier les hashes des commits installés, surveiller les comportements anormaux au moment du composer install ... autant de gestes que nous avons tendance à négliger et qui peuvent bien devenir de véritables vecteurs d'attaque pour nos applications.

Source : https://www.aikido.dev/blog/supply-chain-attack-targets-laravel-lang-packages-with-credential-stealer

Écrit par

Mathieu De Gracia

Lead & Software Architect • nublar.dev