Toda brecha en la cadena de suministro tiene un momento en el que la confianza cambia de manos sin que nadie lo note. El nuestro ocurrió en un sistema que casi ningún equipo revisa: el enlace entre un repositorio de GitHub y un paquete de npm.
Los investigadores de Bloom Security bautizaron el fallo como SlugFest, y la metáfora de su investigador principal, Golan Myers, es la que se quedó: es como una cerradura que revisa la dirección de la puerta en lugar de quién es el dueño de la casa. Cuando el dueño se muda, quien se instala recibe la llave.
Aquí está la parte incómoda. Nadie tuvo que robar una credencial. La única condición previa fue renombrar un repositorio.
Qué debía resolver la publicación de confianza de npm
En julio de 2025 npm lanzó trusted publishing, y la idea era genuinamente buena. En lugar de guardar tokens de npm de larga duración en un servidor de compilación (y filtrarlos por registros, cachés y runners de CI comprometidos), un flujo de trabajo de GitHub Actions solicita un token OpenID Connect de vida corta, lo presenta a npm y recibe a cambio una credencial de publicación. Las versiones llegan con atestaciones de procedencia, así que cualquiera puede rastrear dónde se construyó un paquete.
El diseño elimina toda una clase de incidentes por fuga de secretos. También introdujo un modo de fallo sutil, por un solo campo.
npm vinculó la relación de confianza a la dirección legible del repositorio: owner/repository. Los tokens OIDC de GitHub también llevan el ID numérico permanente del repositorio, que sobrevive a renombrados y transferencias. npm, hasta la primera publicación exitosa de un paquete, ignoraba ese número por completo y comparaba por el nombre.
Los nombres se mueven. Quedan libres cuando un mantenedor renombra, transfiere o elimina un repositorio, y una vez que un nombre está libre, cualquiera puede reclamarlo.
Cómo funciona SlugFest en la práctica
- Un mantenedor configura la publicación de confianza para un paquete, pero aún no ha publicado una versión desde ese repositorio, así que el vínculo sigue basado en el nombre.
- El mantenedor renombra, transfiere o elimina el repositorio. El antiguo slug
owner/repositoryqueda disponible. - Un atacante crea un repositorio nuevo exactamente en ese slug liberado y ejecuta un flujo de publicación. GitHub emite un token OIDC que lleva el nombre reclamado con un ID de repositorio totalmente nuevo.
- npm revisa el nombre, comprueba que coincide con la configuración guardada y entrega un token de publicación para un paquete que el atacante no posee.
A partir de ahí, el atacante publica una versión maliciosa bajo el nombre legítimo del paquete. Los recuentos de descargas, la reputación y todos los proyectos dependientes van de la mano. El escaneo de Bloom en todo el registro encontró más de 1.500 paquetes vulnerables con más de 10 millones de descargas acumuladas y más de un millón de descargas al mes.
Bloom lo reportó a GitHub el 6 de junio de 2026. Se clasificó el 9 de junio. Después el rastro se enfrió durante julio, y la corrección solo llegó cuando los investigadores se preparaban para publicar, más de 120 días después. GitHub y npm ya confirmaron la remediación y se disculparon por la comunicación tardía.
La corrección tiene exactamente la forma correcta: las configuraciones de publicador de confianza recién creadas ahora caducan a las 48 horas salvo que completen una primera publicación exitosa, que valida el vínculo con la identidad inmutable del repositorio. Cambiar la identidad de un repositorio o proyecto requiere una relación de confianza nueva y una ventana nueva de 48 horas. npm también dejó de aceptar tokens de publicación de confianza procedentes de eventos issue_comment, además de la restricción ya existente sobre pull_request_target.
Y entonces llegaron los agentes
Si SlugFest solo afectara a desarrolladores humanos ejecutando npm install, ya sería grave. Es la segunda mitad de la investigación de Bloom la que debería cambiar cómo piensas sobre tu pipeline de compilación.
Bloom estudió millones de agentes de IA en decenas de organizaciones. El endpoint medio recibe alrededor de 70 paquetes instalados por agentes de IA cada mes. Las máquinas de desarrollo llegan cerca de 350. Cada agente instala entre 0,3 y 1,2 paquetes al día; en máquinas de desarrollo, las instalaciones directas son de dos a tres al día, además de todo lo que arrastran esos paquetes. Un endpoint típico ejecuta tres agentes entre interfaces de línea de comandos, IDE, extensiones y asistentes. Las máquinas de desarrollo ejecutan cinco o más.
Ahora alinea eso con el comportamiento de un agente. Resuelve dependencias por su cuenta, prefiere la última versión y casi nunca pregunta de dónde viene un paquete. Una versión maliciosa publicada mediante un slug reclamado se instala y su hook postinstall se ejecuta sin ningún humano en el circuito.
Bloom lo detectó en producción, bloqueando el agente de IA de un cliente cuando intentaba instalar uno de los paquetes afectados.
El beneficio para el atacante es una cascada. Compromete un paquete. Un agente de IA en la máquina de un mantenedor popular lo descarga. Ese endpoint se convierte en la plataforma de lanzamiento de una versión maliciosa del propio paquete del mantenedor, y todos sus consumidores quedan expuestos. Es el patrón Shai-Hulud con acelerante.
La procedencia no es una casilla
Hay un segundo punto ciego que merece atención, porque es el tipo de cosa que sobrevive a una auditoría de cumplimiento.
Una versión maliciosa puede llevar una atestación de procedencia generada por el propio repositorio del atacante. Algunos sistemas de verificación solo comprueban que exista una atestación, no que su origen coincida con el mantenedor del que debía venir el paquete. La firma es real. El firmante está equivocado. Aquí es donde el control de la cadena de suministro tiene que pasar de "¿estaba firmado?" a "¿estaba firmado por la identidad en la que confío, y sigue siendo esa identidad el mismo objeto en el que confié el mes pasado?".
Vale la pena señalar que el Warehouse de PyPI ya almacena identificadores inmutables, que es lo que Bloom recomendó para npm. La ruta de publicación de confianza de npm con GitLab tenía la misma debilidad.
Qué significa esto para los clientes de aratech
La mayoría de las organizaciones no puede arreglar un registro y no va a dejar de usar npm. Lo que sí puede hacer es dejar de tratar la llegada de paquetes como un evento invisible.
- Audita hoy los vínculos de publicador de confianza. Los mantenedores con permisos de publicación deberían ejecutar
npm trust listy confirmar que cada slug configurado sigue resolviendo a un repositorio bajo su control. Cualquier vínculo que apunte a un repositorio renombrado, transferido o eliminado debe borrarse y recrearse. - Trata la higiene de repositorios como trabajo de seguridad. Borrar un vínculo de confianza cada vez que un repositorio se renombra, se transfiere o se elimina debería ser un paso escrito en el runbook, no una buena intención.
- Pon una puerta delante de la ruta de instalación. Un firewall de cadena de suministro que decide qué entra en el entorno es el control que realmente escala, porque no depende de que una persona revise un diff de lockfile a las seis de la tarde.
- Extiende el inventario más allá de los paquetes. Audita extensiones, plugins, servidores MCP, skills y aplicaciones. Bloom encontró el mismo patrón en agosto en Open VSX y el Marketplace de VS Code: 87 paquetes de extensiones en uno y 677 en el otro referenciaban extensiones que no existían, libres para que cualquiera las reclamara.
- Escribe la política de agentes. Qué agentes pueden instalar software, desde qué registros, con qué aprobación y cómo lo sabrías después.
El patrón que conviene recordar
Dos años de historias de seguridad relacionadas con la IA siguen girando alrededor de la misma lección, y SlugFest la formula con claridad: el vínculo entre un nombre legible y la cosa que identifica es la invariante más importante de cualquier sistema de confianza. Rómpelo con un renombrado rutinario y la garantía se derrumba, en silencio, sin alertas y sin un solo inicio de sesión fallido.
Tus agentes ya son infraestructura. Instalan código a velocidad de máquina, en entornos de los que tú respondes. El nombre en la puerta dejó de ser prueba de quién está dentro. Verifica la identidad, no la ortografía, y hazlo de forma automática.