36 paquets npm malveillants exploitent Redis et PostgreSQL
Origines et historique
En avril 2026, des chercheurs ont repéré 36 paquets npm publiés comme des plugins Strapi mais contenant du code malveillant¹. Chaque paquet avait une structure minimale - un package.json, un index.js et un script postinstall.js - sans métadonnées significatives. Le danger n'était pas dans l'apparence du paquet mais dans l'exécution automatique du script postinstall qui se lance lors de l'installation et qui peut agir au nom de l'utilisateur qui installe le paquet².
Cet épisode rappelle des précédents marquants de compromission de la chaîne d'approvisionnement, comme l'affaire event-stream en 2018 où une dépendance prise en charge par un nouveau mainteneur a servi de vecteur pour introduire du code malveillant. Les campagnes de typosquatting et de brand-jacking sur npm amplifient ce risque: des paquets à l'orthographe proche ou au nom trompeur attirent des installations sans vérification attentive.
Les services de données comme Redis et PostgreSQL sont présents partout dans les architectures modernes. Quand leurs configurations sont laxistes - accès réseau ouvert, authentification désactivée ou credentials stockés en clair dans des variables d'environnement - ils deviennent des cibles faciles pour les scripts postinstall qui collectent des secrets et tentent d'étendre l'infection.
Fonctionnement technique
Structure et mécanisme d'activation
Les paquets observés avaient en commun un usage explicite des scripts lifecycle npm pour lancer des actions dès l'installation. Dans package.json on trouve typiquement:
"scripts": { "postinstall": "node postinstall.js" }
Ce mécanisme est documenté et légitime pour automatiser des tâches d'installation, mais il exécute du code avec les mêmes permissions que l'utilisateur qui fait l'installation². Dans un environnement de développement ou, pire, dans un pipeline CI disposant de credentials, cette exécution devient une porte d'entrée pour des attaques.
Capacités observées
Les capacités des paquets varient suivant leur stade d'intrusion, mais plusieurs comportements récurrents ont été notés:
- recherche et lecture de fichiers de configuration et de variables d'environnement (.env, config/database.js, etc.) pour récupérer tokens, mots de passe et endpoints;
- tentatives de connexion aux instances Redis et PostgreSQL accessibles depuis la machine ciblée, en testant plusieurs combinaisons d'hôtes, de ports et d'identifiants;
- exploitation de mauvaises configurations pour écrire sur le système ou exécuter des commandes distantes via des mécanismes fournis par les bases;
- déploiement d'un implant persistant, souvent présenté comme un reverse shell chiffré, capable d'assurer la liaison avec un serveur de commande et contrôle et de télécharger des charges supplémentaires.
Techniques d'exploitation contre Redis
Redis, quand il est accessible sans authentification, offre des vecteurs pratiques pour ancrer un accès persistant. Une chaîne d'actions documentée et souvent reprise par les attaquants est la suivante:
CONFIG SET dir /root/.sshCONFIG SET dbfilename authorized_keysSET""SAVE
Cette suite permet d'écrire une clé SSH dans le répertoire utilisé par sshd, offrant ainsi un accès persistant si le démon SSH accepte les clés déposées. La technique exploite des commandes de configuration et de persistance prévues par Redis; la documentation de durcissement liste des contre-mesures directes pour réduire ce risque⁴.
Techniques ciblant PostgreSQL
PostgreSQL peut aussi servir d'outil d'exfiltration ou de persistance si les permissions sont trop larges ou si des extensions dangereuses sont activées. Des méthodes observées incluent:
- usage de
COPY TOpour écrire un fichier arbitraire sur le système de fichiers si le processus PostgreSQL dispose des droits suffisants; - appel à des extensions permettant d'exécuter des commandes système, par exemple via des fonctionnalités de type
COPY ... TO PROGRAMquand elles sont disponibles; - lecture de fichiers de configuration ou d'artefacts contenant des identifiants si le serveur a un accès disque large.
La portée de ces attaques dépend fortement du niveau de privilège du processus PostgreSQL et des options activées par l'administrateur³.
Implant persistant et exfiltration
Après un accès initial, les attaquants cherchent à maintenir une présence discrète et à extraire les données les plus utiles:
- dépôt de scripts ou de binaires persistants (cron, systemd unit files, etc.);
- établissement d'un canal de commande et contrôle chiffré, avec mécanismes de reconnexion et backoff pour durer malgré les interruptions;
- exfiltration ciblée de secrets - variables d'environnement, fichiers .env, configurations de bases et tokens d'API;
- chargement de modules additionnels pour élargir l'impact: propagation latérale, vol massif, ou pivot vers d'autres services.
Exemples et scénarios observés
36 paquets Strapi (avril 2026)
Les paquets repérés en avril 2026 affichaient des motifs répétitifs: absence d'historique et de métadonnées, scripts postinstall déclenchant des routines d'investigation de l'environnement et de connexion à Redis/PostgreSQL, et payloads modulables selon l'accès obtenu¹. L'hypothèse la plus plausible est une campagne d'auto-publication visant à maximiser la portée via des paquets qui paraissent utiles pour des projets Strapi.
Compromissions historiques de dépendances
Les incidents passés montrent qu'une seule dépendance compromise peut toucher des milliers de projets en quelques heures. La facilité de propagation est amplifiée par les environnements CI où l'installation de dépendances intervient automatiquement avec des privilèges ou des accès à des secrets. Les leçons tirées de ces événements insistent sur la vérification des mainteneurs et la limitation de l'impact des scripts lifecycle.
Risque en CI/CD
Les pipelines automatisés représentent un point d'impact majeur: si un agent CI dispose d'accès à des credentials ou aux environnements de production, un paquet malveillant installé à ce niveau peut propager des accès à l'ensemble de la chaîne de déploiement. La séparation des rôles, la rotation régulière des secrets et l'usage de coffres de secrets réduisent fortement ce risque.
Mesures défensives prioritaires
Pour réduire l'exposition à ce type de campagne, je recommande les actions suivantes, dans l'ordre de priorité pratique:
- restreindre l'accès réseau de Redis et PostgreSQL, activer l'authentification et appliquer le principe du moindre privilège; consulter les guides officiels de durcissement pour chaque produit³ ⁴;
- bloquer ou filtrer l'exécution de scripts lifecycle dans les environnements automatisés: autoriser les postinstall uniquement après revue ou dans des environnements isolés;
- centraliser la gestion des secrets dans un coffre adapté, éviter les variables d'environnement globales contenant des credentials en production;
- maintenir un inventaire des dépendances et adopter des politiques de listes blanches pour les paquets critiques; signer les artefacts et valider les mainteneurs avant intégration;
- ajouter des scans de sécurité et d'intégrité dans les pipelines CI pour détecter les comportements suspects lors de l'installation de paquets.
Sur le plan organisationnel, la facturation et les coûts de remédiation après une compromission de la chaîne d'approvisionnement peuvent rapidement grimper: réponse à incident, rotation de clés, audits et perte de confiance client. Ces coûts justifient un investissement préventif sur le contrôle d'accès et la surveillance continue.
Perspectives
La tendance observée va vers des paquets plus sophistiqués et furtifs: polymorphisme pour échapper aux signatures, utilisation de modules natifs pour contourner l'analyse statique et un ciblage accru des environnements CI et des containers. La communauté des mainteneurs et des équipes DevOps doit renforcer les règles de publication, améliorer la détection des fraudes et intégrer des contrôles pour empêcher l'exécution de scripts non vérifiés dans des environnements sensibles.
La menace évolue rapidement; renforcer les fondamentaux - isolation réseau, authentification, gestion centralisée des secrets et contrôles dans les pipelines - reste la stratégie la plus efficace pour limiter l'impact des prochaines campagnes.
