AgenceEvana
Retour aux bulletins
Élevée2026-04-07CVSS N/Asupply-chainnpmratredispostgresqljavascriptpersistance

36 packages npm malveillants déploient des RATs persistants via Redis et PostgreSQL

36 packages npm malveillants ont été découverts sur le registre public, utilisant des scripts postinstall pour déployer des chevaux de Troie d'accès à distance (RATs) multi-plateformes qui établissent une persistance via Redis et PostgreSQL.

Contexte

En avril 2026, des chercheurs en sécurité ont identifié 36 packages npm malveillants publiés sur le registre public. Ces packages se faisaient passer pour des utilitaires légitimes liés à Redis, PostgreSQL et des outils de développement courants. Une fois installés, leurs scripts postinstall déclenchaient silencieusement le déploiement d'un RAT (Remote Access Trojan) multi-plateformes ciblant Windows, Linux et macOS.

Mécanisme d'attaque

L'attaque se déroule en plusieurs étapes :

  1. Installation silencieuse — le script postinstall s'exécute automatiquement lors de npm install, sans interaction de l'utilisateur
  2. Téléchargement du payload — un binaire RAT est récupéré depuis un serveur distant en fonction de la plateforme détectée (Windows/Linux/macOS)
  3. Exploitation de Redis — le RAT utilise une instance Redis locale ou accessible en réseau pour stocker sa configuration de persistance et ses données de commande
  4. Exploitation de PostgreSQL — des procédures stockées ou des connexions à des bases PostgreSQL exposées servent de canal secondaire pour exfiltrer des données ou recevoir des commandes
  5. Persistance — le RAT s'enregistre comme service système (Windows) ou via crontab/systemd (Linux/macOS)

Packages concernés

Les packages malveillants se présentaient sous des noms évocateurs de bibliothèques légitimes :

  • Faux utilitaires Redis (redis-helper, redis-utils-client, variations)
  • Faux connecteurs PostgreSQL (pg-connect-utils, postgres-driver-helper, variations)
  • Faux outils de développement généralistes imitant des packages populaires par typosquatting

La majorité des packages avaient moins de 500 téléchargements, suggérant un ciblage précis plutôt qu'une diffusion de masse.

Impact

Un environnement compromis permet à l'attaquant de :

  • Exécuter des commandes arbitraires sur la machine de développement ou le serveur CI/CD
  • Exfiltrer des secrets — variables d'environnement, clés SSH, tokens cloud, credentials de bases de données
  • Pivoter sur le réseau interne via les connexions Redis/PostgreSQL existantes
  • Maintenir un accès persistant même après redémarrage de la machine

Détection

Vérifiez si votre environnement est affecté :

# Lister tous les packages installés avec leurs scripts postinstall
npm ls --json | jq '.. | .scripts?.postinstall? | select(.)'

# Rechercher des connexions sortantes suspectes établies après npm install
# (Linux/macOS)
ss -tnp | grep node

# Vérifier la présence de crontabs suspects
crontab -l
cat /etc/cron.d/*

# Auditer les packages récemment installés
npm audit

Signes d'infection :

  • Processus node actifs sans raison apparente après installation
  • Nouvelles entrées dans crontab ou services système créés après npm install
  • Connexions sortantes vers des IPs inconnues depuis des processus liés à Node.js
  • Requêtes Redis ou PostgreSQL inhabituelles dans les logs

Remédiation

  1. Supprimez les packages suspects identifiés dans votre node_modules
  2. Effectuez une rotation immédiate de tous les secrets accessibles sur la machine concernée
  3. Isolez la machine du réseau si une infection active est suspectée
  4. Réinstallez depuis un environnement propre — ne réutilisez pas un node_modules potentiellement compromis
  5. Auditez vos instances Redis et PostgreSQL — vérifiez la présence de clés ou procédures inattendues : 
    # Redis : lister toutes les clés
redis-cli KEYS "*"

# PostgreSQL : lister les procédures stockées récentes
SELECT proname, prosrc FROM pg_proc WHERE prolang != 12 ORDER BY oid DESC LIMIT 20;
  6. Activez l'authentification sur Redis si ce n'est pas déjà le cas — Redis sans auth exposé localement est un vecteur courant

Recommandations

  • Vérifiez les scripts postinstall avant d'installer un package inconnu : npm pack <package> puis inspectez le contenu
  • Utilisez --ignore-scripts pour les environnements de production où les scripts postinstall ne sont pas nécessaires : npm install --ignore-scripts
  • Activez l'authentification et le binding local sur Redis — ne jamais exposer Redis sur 0.0.0.0 sans authentification
  • Restreignez les privilèges PostgreSQL — les connexions applicatives ne devraient pas avoir les droits SUPERUSER
  • Intégrez un scanner de supply chain (Socket.dev, Snyk, Dependabot) dans votre pipeline CI/CD pour détecter les comportements suspects dans les scripts d'installation
Retour aux bulletins