Quand Prettier devient un vecteur d’infection : attaque supply chain sur npm, c’est le genre de titre qu’on aimerait croire sorti d’un article satirique. Et pourtant, la compromission récente de deux packages npm ultra-populaires (eslint-config-prettier et eslint-plugin-prettier) est bien réelle. En exploitant un phishing ciblé contre les mainteneurs, des attaquants ont injecté du code malveillant dans ces bibliothèques, les transformant en droppers de malware capables de contaminer développeurs, environnements de build et pipelines CI/CD. Cette attaque supply chain sur npm illustre une nouvelle fois à quel point notre écosystème open source est devenu une cible de choix… et un cauchemar latent pour la sécurité des entreprises.
đź“Ś Paquets compromis :
eslint-config-prettiereslint-plugin-prettier
➡️ Des packages très populaires, utilisés dans des millions de projets JavaScript/Node.js.
Bienvenue dans l’ère du « npm install && infect ».
📦 Le point de départ : la crédulité des mainteneurs open source
Tout commence par un scénario désormais bien rodé :
- Un développeur mainteneur reçoit un mail piégé.
- Il clique (parce qu’il est humain).
- Ses identifiants npm tombent dans les mains des attaquants.
- Ces derniers publient une nouvelle version piégée des bibliothèques ESLint.
Et voilà . Vous faites un npm install, vous ne vous méfiez de rien… et vous venez de lancer un script postinstall qui télécharge un binaire malveillant sur votre poste ou dans votre pipeline CI/CD.
Si c’était un film, on appellerait ça « Beautify me softly ».
🧾 Fiche d’incident – SecuSlice
| Élément | Détail |
|---|---|
| Type d’incident | Attaque chaĂ®ne d’approvisionnement (npm) |
| Origine | Phishing ciblé sur les mainteneurs |
| Impact | Prise de contrĂ´le des packages, propagation de malware |
| Packages compromis | eslint-config-prettier, eslint-plugin-prettier |
| Infection | Injection d’un script malveillant via postinstall |
| Cibles | DĂ©veloppeurs, build pipelines, environnements CI |
| Statut | Paquets désindexés par npm, mais infections possibles |
| Score de sévérité | 🔴 Critique – niveau 9.5+ (estimé) |
| Actions recommandées | Audit complet des dépendances, suppression des versions compromises, vérification des logs CI/CD |
🎯 Les victimes : des développeurs… et leur CI/CD
Ce qui rend cette attaque particulièrement redoutable, c’est son discret ciblage :
- Ces packages sont des outils de mise en forme de code. On les installe souvent enÂ
devDependencies, sans y penser. - Ils sont appelés dans des projets open source, mais aussi dans des repositories privés, des environnements de build, et même des images Docker.
Le malware n’a pas été détaillé dans son intégralité, mais selon les premières analyses, il permet :
- De collecter des données système,
- D’exfiltrer des tokens, des clĂ©s SSH, ou des fichiersÂ
.env, - Et potentiellement d’installer une porte dĂ©robĂ©e persistante.
Moralité : la moindre npm install sur un runner CI peut devenir un acte suicidaire si vous ne maîtrisez pas vos dépendances.
Voir notre article sur la sécurité des pipelines : Sécuriser un pipeline CI/CD : mission (im)possible ?
🧨 Une attaque « low-tech », efficacité « high-impact »
Ce qui est ironique ici, c’est que rien n’est innovant :
- Pas de CVE spectaculaire,
- Pas d’exploitation complexe,
- Juste de la confiance exploitĂ©e, et unÂ
package.json piégé.
Comme dans 90 % des attaques modernes, le point d’entrée est humain, et la cible, c’est la chaîne d’approvisionnement logicielle.
Les pirates ne cherchent plus à casser des firewalls. Ils cassent la chaîne de confiance entre développeurs et écosystème.
Et vous savez quoi ? Ça marche.
🧪 Comment savoir si vous êtes touché
Si vous avez installé ces packages récemment, surtout entre le 17 et le 19 juillet 2025, vous devez :
- VĂ©rifier vos fichiersÂ
package-lock.json ouÂyarn.lock. - Supprimer les versions compromises.
- Regénérer vos environnements (
npm ci,Âdocker build, etc.). - RĂ©voquer tous les secrets potentiellement exposĂ©s (tokens, clĂ©s, variables d’environnement).
- Auditer les logs CI/CD pour toute activité suspecte.
Un bon grep dans vos dépôts vaut mieux qu’un long discours.
âś… Que faire maintenant ?
- 📦 Supprimez immédiatement toute version installée après le 17 juillet 2025.
- 🔒 Réinitialisez vos secrets dans les projets ayant ces dépendances.
- 🛡️ Auditez vos pipelines CI/CD pour détecter toute activité anormale.
- 🧪 Utilisez un scanner de dépendances type npm audit ou Snyk.
- 💡 Activez l’authentification 2FA obligatoire pour les mainteneurs npm.
🧠Commentaires SecuSlice
Encore une attaque chirurgicale sur la supply chain JavaScript, via ce bon vieux phishing ciblé. Le malware n’avait même pas besoin de 0-day, juste de la confiance de la communauté npm.
📦 Quand vos outils de qualité de code (eslint + prettier) deviennent des vecteurs d’infection, on touche le fond.
🛡️ Bonnes pratiques (que personne n’applique jusqu’au drame)
Soyons honnĂŞtes :
🔸 Qui vérifie les dépendances d’un plugin ESLint ?
🔸 Qui active l’option de vérification des intégrités (package-lock) ?
🔸 Qui impose la 2FA sur tous ses mainteneurs npm ?
Pas grand monde. Et les attaquants le savent.
Voici donc la checklist de survie du jour :
- ✅ Activez la 2FA obligatoire sur tous les comptes npm.
- ✅ N’installez jamais de paquets sans les verrouiller par version.
- ✅ Utilisez des outils comme Snyk, npm audit, ou socket.dev pour scanner les dépendances.
- ✅ Ne faites jamais confiance à un outil de dev « par défaut ».
Même pas Prettier. Surtout pas Prettier.
🔚 Conclusion : le ver est dans le linter
L’histoire de ce détournement est un rappel brutal : la supply chain logicielle est une passoire, et l’open source n’est pas gratuit — il coûte du temps, de la sécurité, et de la vigilance. La prochaine fois que vous ferez un npm install, souvenez-vous que même les outils qui rendent votre code plus joli peuvent cacher un cauchemar bien laid.
🎯 Et maintenant, tous ensemble : auditons nos dépendances, sécurisons nos pipelines, et envoyons des cafés aux mainteneurs épuisés. Ils en ont besoin.
