Puerta trasera: Ataque coordinado a la cadena de suministro en npm, PyPI y Crates – qué deben

El 22 de mayo de 2026, a las 20:20 UTC, una cuenta de PyPI subió el paquete eth-security-auditor 0.1.0. Para cuando Socket clasificó la oleada como TrapDoor, ya había 34 paquetes más en npm, PyPI y Crates.io. Tiempo medio de detección por versión: 5 minutos y 27 segundos. Quien inicie un CI/CD-Run en ese intervalo tiene un problema que ninguna demo de proveedor explica.

Relacionado:NIS2 y CLOUD Act  /  Cumplimiento de NIS2 en pymes

Por qué esta oleada no se parece al typosquatting

¿Qué es TrapDoor? TrapDoor es la denominación que los investigadores de seguridad de Socket dan a un ataque coordinado a la cadena de suministro en mayo de 2026, en el que se infiltraron más de 34 paquetes maliciosos en paralelo en npm, PyPI y Crates.io, con el objetivo de robar keystores de wallets, claves SSH, credenciales en la nube y configuraciones de editores de IA. El clúster lleva el marcador interno P-2024-001 y está vinculado a la cuenta de GitHub ddjidd564 y a la cuenta de npm asdxzxc.

Las campañas habituales de typosquatting dependen del azar. Alguien se equivoca al teclear en *npm install*, un paquete con un nombre similar entrega una carga oculta. TrapDoor funciona de otra manera. Los paquetes tienen nombres como *prompt-engineering-toolkit*, *solidity-deploy-guard* y *defi-threat-scanner*. Se hacen pasar por herramientas para el público objetivo exacto que el atacante quiere explotar: desarrolladores en entornos de cripto, DeFi, Solana e IA.

La segunda diferencia con respecto a una oleada típica de npm es la amplitud en los registros. Tres gestores de paquetes a la vez, con la misma huella del actor de la amenaza, la misma cuenta de GitHub *ddjidd564* y el mismo marcador. Esto es una operación planificada, no un script de principiante.

Y es rápido. Socket informa de un tiempo medio de detección de 5 minutos y 27 segundos en 381 registros de versiones con marcas de tiempo completas. El hallazgo más rápido se produjo 58 segundos después de la publicación. Quien ejecute un *npm install* o *pip install* en uno de estos intervalos en un runner de CI no controlado, tendrá mala suerte.

Cómo el ataque se ramifica por registro

Los paquetes comparten una arquitectura de destino, pero con diferentes activadores por ecosistema. En npm, la carga útil se adjunta a postinstall, en Rust el código se extrae a través de build.rs, y en Python se ejecuta en el momento de la importación. Esta separación es relevante porque afecta exactamente a los tres puntos en los que los sistemas de construcción ejecutan automáticamente código externo sin que el usuario lo inicie explícitamente.

Se recopilan claves SSH, credenciales de AWS, tokens de GitHub, bases de datos de inicio de sesión del navegador, almacenes de claves de billetera para Sui, Solana y Aptos, variables de entorno, claves API y configuraciones locales de desarrollo. Esto representa la visión completa de un perfil de estación de trabajo de desarrolladora promedio, incluyendo todas las persistencias en la nube.

Dónde TrapDoor realmente innova: configuraciones de codificación con IA

El ataque tiene un vector que el código malicioso habitual de la cadena de suministro no posee. TrapDoor manipula los archivos de configuración de Cursor y Claude Code directamente. Concretamente: cursorrules y Proyecto-CLAUDE.md se modifican con caracteres Unicode de ancho cero que permanecen invisibles para el revisor en el editor, pero que el asistente de IA interpreta como prompt.

El resultado es una instrucción camuflada que lleva al asistente a ejecutar sus propios escaneos de seguridad o rutinas de diagnóstico, que en realidad exportan datos del contexto del proyecto. Quien trabaje con un editor asistido por IA y no controle las versiones de los archivos de configuración del repositorio, tiene una vía que la detección de endpoints habitual no ve. Esta es la primera ola documentada de cadena de suministro que utiliza agentes de IA como capa de coejecución.

Quien se lo tome en serio en el equipo, tratará cursorrules y Proyecto-CLAUDE.md a partir de hoy como scripts de construcción. Revisiones diff por commit, verificación de codificación para anomalías Unicode, y ningún merge sin cuatro ojos.

Mitigaciones en CI/CD: qué funciona y qué falla

Los filtros de egreso son la palanca subestimada. Incluso si un postinstall malicioso se ejecuta en la construcción, sin una conexión saliente a redes de terceros no tiene destino para las credenciales. Quien hoy opere su ejecutor de GitHub Actions o GitLab en una VPC plana sin reglas de egreso, no avanzará con npm audit.

El segundo ganador silencioso es OIDC. Una construcción que obtiene su token efímero de AWS en el momento de la ejecución desde el emisor OIDC del CI, no tiene una clave en la nube de larga duración que TrapDoor pueda robar. Esto desplaza la ventana de ataque del secreto permanente a la duración de la construcción.

NIS2 y DORA: dónde el tema ya es obligatorio documentar

El artículo 21 de NIS2 incluye la seguridad de la cadena de suministro como una de las medidas mínimas de gestión de riesgos que debe implementar un proveedor esencial o importante. Concretamente: evaluación documentada de los proveedores directos y prestadores de servicios, incluidas las dependencias de software. Una dependencia npm en una build utilizada en producción no es jurídicamente menos proveedor que un módulo de control adquirido externamente.

DORA exige para el sector financiero, en los artículos 28 y 30, un inventario completo de terceros de TIC más los riesgos de concentración documentados. Quien, como banco o entidad financiera, utilice un repositorio npm con cientos de dependencias transitivas sin incluirlas en el registro de terceros de TIC, tendrá un flanco abierto en la próxima auditoría.

Ambos marcos normativos no exigen una protección completa contra paquetes de día cero, pero sí un proceso trazable. Aquí es donde reside la palanca de NIS2 y DORA para los responsables de seguridad: TrapDoor se convierte en un caso práctico concreto con el que medir los propios procesos de cadena de suministro.

Cuatro semanas son una ventana realista si el equipo de seguridad redacta los tickets y el equipo de plataforma construye. El orden es intencionadamente asimétrico: egreso antes que SBOM, antes que OIDC, antes que configuración de IA. Quien siga este orden cierra primero las vías por las que TrapDoor exfiltra datos y luego se ocupa de los temas estructurales.

Qué queda por resolver

Socket describe un atacante que sabe mucho sobre sistemas de build modernos y editores de IA. La próxima oleada probablemente no se encuentre en paquetes pep o npm, sino en Helm Charts, imágenes base de contenedores o directamente en flujos de trabajo de GitHub Actions. Quien archive TrapDoor solo como un incidente npm, está planeando al margen del próximo vector.

Conviene tratar desde hoy la propia plataforma de CI/CD como un sistema de producción en funcionamiento, no como una herramienta auxiliar. Con todo lo que ello implica: línea base de hardening, monitorización, manual de incidentes y responsabilidades documentadas.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.