TrapDoor: un ataque coordinado golpea npm, PyPI y Crates.io, y GitHub responde con 2FA obligatorio

Concepto: ataque a la cadena de suministro de software

Una campaña coordinada de cadena de suministro bautizada TrapDoor distribuyó malware roba-credenciales a través de más de 34 paquetes maliciosos en npm, PyPI y Crates.io. Casi en paralelo, GitHub activó en npm la publicación escalonada con doble factor obligatorio para frenar este tipo de ataques.

La empresa de seguridad Socket detectó la operación, que comenzó el 22 de mayo de 2026 a las 20:20 UTC y publicó paquetes en oleadas a lo largo de los días siguientes. En total se contabilizaron 21 paquetes en npm, 7 en PyPI y 6 en Crates.io, sumando más de 384 versiones comprometidas.

Qué hace TrapDoor y a quién apunta

El malware está dirigido sobre todo a desarrolladores de los ecosistemas cripto, DeFi, Solana e IA, y su objetivo es robar billeteras de criptomonedas, claves SSH y credenciales almacenadas. Para activarse usa el punto de entrada propio de cada ecosistema:

  • npm: hooks de postinstall que se ejecutan al instalar el paquete.
  • PyPI: ejecución en tiempo de importación (import-time).
  • Crates.io (Rust): el script de compilación build.rs.

Pero el detalle más novedoso —y preocupante— es que TrapDoor apunta deliberadamente a los asistentes de IA para programar. Modifica archivos de configuración como .cursorrules y CLAUDE.md, e inyecta instrucciones maliciosas ocultas con caracteres Unicode de ancho cero, invisibles para el desarrollador pero leídas por el asistente. Es, en la práctica, envenenamiento de prompts dentro del propio repositorio.

Como referencia de la velocidad del fenómeno: Socket detectó cada publicación de TrapDoor en un promedio de 5 minutos y 56 segundos, y en el caso más rápido, a los 58 segundos de subido el paquete.

No es un caso aislado

TrapDoor se suma a una ola sostenida de ataques a la cadena de suministro de software de las últimas semanas: paquetes de Laravel Lang secuestrados vía tags de Git, ocho paquetes infectados en Packagist, y campañas masivas contra repositorios open source. Viene además después de la brecha que comprometió 3.800 repositorios internos de GitHub a partir de una extensión maliciosa de VS Code, que ya cubrimos en su momento.

La respuesta: 2FA obligatorio y publicación escalonada

Del lado de las plataformas, GitHub anunció el 22 de mayo nuevos controles para npm orientados justamente a cortar este vector. Los principales:

  • Publicación escalonada (staged publishing). Ya disponible de forma general. En vez de publicar directo, el paquete queda en una cola de preparación y un mantenedor humano debe aprobarlo pasando un desafío de doble factor (2FA) antes de que sea instalable. Se usa con el comando npm stage publish y requiere la CLI de npm 11.15.0 o superior.
  • Controles de instalación. Tres nuevos flags —--allow-file, --allow-remote y --allow-directory— que se suman al ya existente --allow-git para limitar desde dónde se permite instalar dependencias.
  • Recomendación oficial. GitHub aconseja combinar la publicación escalonada con trusted publishing vía OIDC, para evitar el uso de tokens de larga duración.

La contracara es la fricción: publicar deja de ser instantáneo y suma un paso manual. Pero es una compensación razonable frente a un patrón de ataque que ya demostró poder colarse en millones de instalaciones a partir de una sola credencial comprometida.

Qué conviene revisar ahora

  • Auditar los lockfiles y las dependencias recientes, prestando atención a versiones publicadas a partir del 22 de mayo.
  • Rotar credenciales sensibles (claves SSH, tokens, billeteras) si hubo instalaciones sospechosas.
  • Actualizar la CLI de npm y evaluar activar publicación escalonada con 2FA en los paquetes propios.
  • Revisar los archivos de configuración de los asistentes de IA (.cursorrules, CLAUDE.md) en busca de contenido oculto.

La confianza en las dependencias, en revisión

Cada incidente como TrapDoor erosiona un supuesto que el desarrollo moderno daba por sentado: que instalar un paquete popular es seguro. ¿Tu pipeline ya audita lo que entra por las dependencias, o todavía confía a ciegas en el lockfile? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →
Suscribirse
Notificarme de
guest

0 Comentarios
Viejos
Nuevos Más votados
Feedback entre líneas
Ver todos los Comentarios
Scroll al inicio
0
Nos encantaría conocer tu opinión: ¡comenta!x