En el registro oficial de npm se ha identificado una campaña de 36 paquetes maliciosos que se presentaban como supuestos plugins para la CMS Strapi. Estos paquetes estaban diseñados para explotar servicios Redis y PostgreSQL, desplegar reverse shells, robar credenciales y mantener implantes persistentes en los sistemas comprometidos. El incidente se suma a la tendencia creciente de ataques a la cadena de suministro de software, donde las propias herramientas de desarrollo se convierten en vehículo de distribución de código malicioso.
Paquetes npm maliciosos disfrazados de plugins de Strapi
Según el análisis de SafeDep, todos los paquetes compartían una estructura mínima casi idéntica: únicamente tres archivos — package.json, index.js y postinstall.js. Carecían de descripción, enlace a repositorio o página oficial, pero se distribuían con la versión 3.6.8, imitando a un plugin “maduro” compatible con Strapi v3 dentro del ecosistema de la comunidad.
Los nombres seguían el patrón «strapi-plugin-« seguido de términos genéricos como “cron”, “database” o “server”. Esta convención reproduce la forma habitual de nombrar extensiones legítimas y facilita que los desarrolladores menos atentos los confundan con componentes fiables. Sin embargo, los plugins oficiales de Strapi se publican bajo el espacio de nombres @strapi/, un detalle clave para distinguir módulos legítimos de paquetes fraudulentos en npm.
Los 36 paquetes se subieron en un intervalo aproximado de 13 horas, utilizando cuatro cuentas ficticias de npm: «umarbek1233», «kekylf12», «tikeqemif26» y «umar_bektembiev1». Este comportamiento concentrado en el tiempo es típico de campañas que buscan una rápida propagación antes de ser detectadas y eliminadas.
Técnicas de ataque: scripts postinstall, explotación y persistencia
Abuso de scripts postinstall en npm para ejecutar código oculto
La lógica maliciosa se concentraba en el script postinstall, que se ejecuta automáticamente cuando el usuario lanza «npm install». Cualquier código definido en este tipo de scripts se ejecuta sin interacción adicional y con los mismos privilegios que la cuenta que realiza la instalación. En entornos de CI/CD, contenedores Docker o instalaciones realizadas como root, esto otorga al atacante un nivel de acceso muy elevado.
Este caso ilustra un riesgo estructural del ecosistema npm: cualquier paquete con scripts de ciclo de vida (lifecycle scripts) puede ejecutar código arbitrario en el momento de la instalación. Cuando este mecanismo se combina con cadenas de suministro complejas y automatizadas, se convierte en un vector de ataque extremadamente atractivo.
Evolución de la carga útil: de explotación agresiva a espionaje y robo de credenciales
SafeDep identificó ocho variantes de payload utilizadas a lo largo de la campaña, que muestran una clara evolución táctica:
1. Fase inicial agresiva. Las primeras versiones intentaban ejecución remota de código (RCE) a través de Redis y escape de Docker para salir del contenedor y tomar control del host subyacente.
2. Reconocimiento y mapeo del entorno. Ante la baja efectividad de las técnicas directas de explotación, el atacante pivotó hacia el reconocimiento interno, recopilando información del sistema, servicios expuestos y configuraciones críticas.
3. Acceso directo a bases de datos PostgreSQL. El código contenía credenciales y hosts de PostgreSQL codificados de forma estática, permitiendo conexiones directas a la base de datos, eludiendo por completo las capas de la aplicación.
4. Persistencia y robo selectivo de credenciales. En las últimas iteraciones, el foco pasó a instalar un implante persistente, desplegar un reverse shell y extraer de forma dirigida credenciales, claves API y otros secretos sensibles.
La combinación de interés en bases de datos, orientación a activos digitales y uso de credenciales embebidas apunta a una alta probabilidad de que la campaña estuviera dirigida contra una plataforma de criptomonedas o servicios fintech.
Contexto: auge de los ataques a la cadena de suministro de software
El hallazgo de estos falsos plugins de Strapi encaja en una ola más amplia de ataques a la cadena de suministro en open source. Un informe de Group-IB de febrero de 2026 describe este tipo de ataques como «la fuerza dominante que está moldeando el panorama global de ciberamenazas», ya que permiten a los atacantes obtener acceso heredado a cientos de organizaciones a través de proveedores y dependencias de confianza.
Repositorios de paquetes como npm y PyPI se han convertido en objetivos prioritarios: se explotan cuentas de mantenedores, se automatiza la infección masiva de librerías y se introduce código malicioso directamente en los procesos de compilación. Como consecuencia, los pipelines de CI/CD actúan, en la práctica, como grandes canales de distribución de malware.
La experiencia de incidentes anteriores en la cadena de suministro —como compromisos de librerías populares en npm o ataques a herramientas de desarrollo ampliamente desplegadas— demuestra que un único punto de fallo puede tener un impacto transfronterizo, afectando tanto a equipos de desarrollo como a sus clientes finales.
Recomendaciones para proteger la cadena de suministro de software
Las organizaciones que hayan instalado alguno de los paquetes implicados deben asumir compromiso y actuar con rapidez: rotar todas las credenciales (incluyendo bases de datos, claves API y secretos de CI/CD), revisar registros en busca de actividad anómala y reinstalar servicios críticos desde imágenes y artefactos confiables.
1. Validación estricta de dependencias. Verificar siempre el namespace (en Strapi, únicamente @strapi/), el repositorio, el historial de versiones y el volumen de descargas. Desconfiar de paquetes sin descripción, sin origen transparente o con señales de creación reciente y masiva.
2. Control de scripts de ciclo de vida. En entornos sensibles, emplear opciones que bloqueen la ejecución de scripts en la instalación, como npm install –ignore-scripts, y auditar de forma específica cualquier dependencia que requiera lifecycle scripts.
3. Uso de SCA y repositorios internos. Implementar herramientas de Software Composition Analysis (SCA), mantener espejos internos de npm y definir políticas de allowlist/denylist para las bibliotecas permitidas en los proyectos.
4. Refuerzo de la seguridad en CI/CD y contenedores. Evitar el uso de root en contenedores siempre que sea posible, aplicar el principio de mínimo privilegio en pipelines, segmentar accesos y revisar regularmente los secretos almacenados en plataformas de orquestación.
La proliferación de paquetes npm maliciosos que se hacen pasar por plugins populares confirma que cada fase del ciclo de vida del software es hoy un objetivo potencial. Tratar las dependencias con el mismo rigor que la infraestructura de producción, combinar controles técnicos con buenas prácticas de desarrollo seguro y mantenerse actualizado sobre seguridad en la cadena de suministro son pasos esenciales para reducir el riesgo y fortalecer la resiliencia frente a futuras campañas similares.
