Alerte Supply Chain

Quand Shai-Hulud s'attaque à PHP Composer et paralyse l'écosystème Laravel

Dans nos précédents articles, nous avons cartographié pas à pas l'une des campagnes de cyberdélinquance les plus sophistiquées de cette année. Nous avons vu comment le malware Shai-Hulud ciblait initialement les ingénieurs IA, comment il s'est infiltré chez GitHub en transformant le poste de travail en cheval de Troie, puis comment il a utilisé l'extension VS Code Nx Console comme vecteur de propagation autonome en mode "ver".

Si les développeurs backend PHP se croyaient jusqu'ici à l'abri, protégés par les barrières étanches de leurs écosystèmes respectifs, la réalité vient de les rattraper brutalement. Depuis le 22 mai, la campagne s'est étendue avec une violence inouïe à l'univers PHP/Laravel, frappant au cœur du gestionnaire de dépendances Composer.

Voici l'analyse technique de cette nouvelle extension de la menace, la méthode d'empoisonnement inédite utilisée par l'attaquant, et le guide complet pour diagnostiquer et assainir vos infrastructures.

🔗 Rappels de notre série spéciale Menaces Supply Chain :

1. Sécurité : Un malware cible les développeurs IA (L'anatomie de Shai-Hulud)
2. GitHub impacté par une attaque : Quand le poste de dev devient la porte d'entrée (L'impact infrastructurel)
3. De Shai-Hulud à Nx Console : L'effet domino qui transforme le poste de dev en arme de destruction massive (La propagation par les extensions d'IDE)

---

Laravel-Lang : Le piratage par réécriture de l'Histoire (Git Tags)

L'attaque, documentée par The Hacker News, a pris pour cible l'organisation communautaire Laravel-Lang, dont les packages de localisation et de traduction (laravel-lang/lang, attributes, http-statuses, et actions) comptent des dizaines de millions de téléchargements et s'avèrent présents par défaut dans la quasi-totalité des architectures Laravel mondiales.

Pour contourner la vigilance des développeurs, l'attaquant n'a pas publié une nouvelle version mineure ou majeure (qui aurait immédiatement alerté les outils d'audit automatique). Il a piraté les accès de l'organisation pour réécrire l'intégralité des versions historiques (les Git Tags stables) déjà existantes.

En modifiant ces pointeurs durant une fenêtre critique entre le 22 et le 23 mai, l'attaquant a forcé Packagist (le répertoire public PHP) à distribuer du code malveillant à quiconque exécutait une réinstallation ou une mise à jour, même sur des versions figées depuis plusieurs années.

L'anatomie de la charge utile : L'exécution furtive via autoload

Le malware injecté dans l'écosystème PHP conserve les mêmes objectifs obsessionnels que ses homologues JavaScript et Python : l'exfiltration massive de secrets.

Cependant, sa méthode d'activation en PHP est redoutable. L'attaquant a injecté un script malveillant de près de 6 000 lignes dans un fichier src/helpers.php, directement enregistré sous la directive autoload.files du manifeste composer.json.

Conséquence directe : Le code malveillant n'attend pas qu'une fonction spécifique soit appelée. Il s'exécute automatiquement, en tâche de fond, à chaque fois que l'environnement PHP démarre. Cela englobe :

• Chaque requête HTTP reçue par votre application Laravel.
• Chaque exécution de commande dans le terminal via php artisan.
• Chaque lancement de tests unitaires via phpunit ou pest.

Une fois activé, le script scanne le serveur ou le poste local à la recherche du graal : le fichier .env, les configurations cloud de production (AWS, GCP), les tokens d'accès aux LLMs (Mistral AI, Anthropic), ainsi que les sessions de coffres-forts comme 1Password. Les données sont immédiatement chiffrées et exfiltrées vers un serveur de commande (C2).

---

Guide de Diagnostic : Comment vérifier si vous êtes safe ?

Si vos équipes travaillent sur des stacks PHP / Laravel, vous devez impérativement mener un audit immédiat selon la procédure suivante.

1. L'analyse temporelle (La fenêtre de tir)

Le premier diagnostic repose sur l'historique de vos builds. Posez-vous la question suivante : Un développeur de mon équipe ou notre serveur de CI/CD a-t-il exécuté un composer update ou un composer install (sans fichier lock ou avec suppression du cache) entre le 22 mai et le 23 mai au soir ?

• Si NON : Le risque d'infection directe est extrêmement faible.
• Si OUI : Le poste ou le conteneur de build doit être immédiatement isolé du réseau pour investigation.

2. L'audit du fichier de verrouillage (composer.lock)

Ouvrez le fichier composer.lock de vos projets en production et inspectez la section dédiée aux paquets laravel-lang.

• Vérifiez la clé dist. Si l'URL de téléchargement pointe vers un dépôt tiers, un fork inconnu, ou si le hash SHA-1 ne correspond pas aux standards habituels de l'organisation officielle, le paquet est corrompu.
• Règle d'or : Si votre fichier composer.lock a été généré et validé avant le 21 mai 2026, et qu'aucune installation globale n'a écrasé vos caches, votre code source est sain.

3. La détection des processus et connexions réseaux

Sur les postes de développement ou les serveurs de staging suspects, observez les connexions réseau sortantes initiées par PHP pendant l'exécution de l'application :

# Sur macOS / Linux - Traquer les sockets actives de PHP
sudo lsof -i -P -n | grep php

Si vous observez des requêtes HTTPS sortantes vers des adresses IP publiques non documentées au moment précis où vous lancez une commande php artisan, la machine est compromise.

---

Procédure d'assainissement et de remédiation

Si une compromission est détectée, n'agissez pas à l'aveugle. Comme nous l'évoquions dans notre premier volet, le malware intègre une fonction d'auto-défense destructrice (un script de nettoyage agressif de type rm -rf ~/) s'il détecte une tentative de révocation de ses droits à chaud alors que la machine est connectée.

1. Isolation : Déconnectez immédiatement la machine du réseau (coupez le Wi-Fi, débranchez le câble).
2. Purge des caches Composer : Nettoyez intégralement les caches locaux qui pourraient contenir des résidus des tags Git altérés :

composer clear-cache

3. Restauration de l'état d'origine : Supprimez le répertoire vendor et réinstallez vos dépendances exclusivement à partir d'un fichier composer.lock certifié sain et antérieur à l'attaque :

rm -rf vendor/
composer install --frozen-lockfile --no-cache

4. Rotation des Secrets (Depuis un poste tiers sain) : Procédez au renouvellement immédiat de toutes les variables d'environnement présentes dans votre fichier .env (clés d'API IA, accès aux bases de données, clés secrètes AWS, tokens GitHub).

Conclusion : Vers un cloisonnement strict des environnements de dev

L'extension de la campagne Shai-Hulud à PHP Composer prouve que les attaquants ne ciblent pas un langage plutôt qu'un autre, mais bien le maillon faible de la chaîne : le poste du développeur. Qu'il écrive du TypeScript, du Python ou du PHP, l'ingénieur dispose de clés d'accès maîtresses vers les infrastructures de l'entreprise.

Chez FINE TURING, nous réitérons notre recommandation stratégique : l'ère des installations de packages "à la volée" directement sur la machine hôte est révolue. L'isolation des environnements d'exécution via des conteneurs dédiés sans privilèges, l'usage systématique de dépôts miroirs privés dotés de proxies de sécurité, et la rotation automatisée à haute fréquence des secrets de configurations sont désormais les seules armes viables pour protéger la supply chain des entreprises.

Restez alignés, restez isolés, restez vigilants.