# Slopsquatting, guía de seguridad para la cadena de suministro > Slopsquatting, nombres de paquete alucinados por la IA y tres ataques reales de 2026. Guía de defensa con controles que puedes desplegar esta semana. > Por José Maldonado · Ciberseguridad · 2026-10-17 Tu IA te propone una dependencia que no existe, la aceptas y comienza el desastre. Y no, no se trata de un «simple desliz», el modelo de IA en el que tanto confías simplemente se ha inventado el paquete con aplomo, con una sintaxis impecable, y tú simplemente, por confianza ciega, ejecutas la instalación sin sospechar. Ese es el punto de partida del slopsquatting, la variante del robo de nombres de paquete en la que el error no lo comete una persona, sino una máquina que predice texto con una seguridad desconcertante. El fenómeno tiene cifras. El estudio presentado en USENIX Security 2025 por [Spracklen y su equipo](https://www.usenix.org/conference/usenixsecurity25/presentation/spracklen) generó 576.000 muestras de código con 16 modelos y encontró 205.474 nombres de paquete inventados que no existían en ningún registro, con tasas de alucinación del 5,2% en modelos comerciales y del 21,7% en modelos abiertos. Una reevaluación publicada en 2026 sobre cinco modelos de frontera midió entre el 4,62% y el 6,10%, y localizó 127 nombres que los cinco inventaban igual, 53 de ellos todavía disponibles para que un atacante los registrara. La segunda mitad de 2026 convirtió el concepto en agenda. El 3 de octubre, [OX Security](https://www.ox.security/academy/code-security/slopsquatting-when-ai-hallucinates-package-names-and-attackers-move-in/) publicó el manual más ordenado de la amenaza; el 6 de octubre, GitLab presentó un cortafuegos de dependencias en acceso anticipado, y el 8 de octubre, [Sonatype](https://www.sonatype.com/blog/hijacked-tensorlake-npm-turned-install-into-credential-risk) documentó el secuestro de la versión 0.5.144 del paquete `npm tensorlake`, con un gancho de instalación que iba a buscar credenciales. Los incidentes de esas semanas tienen un rasgo común y bastante incómodo: viajaron por tuberías legítimas, con certificados de procedencia válidos y sin que nadie escribiera mal un solo nombre. ## ¿Qué es el slopsquatting y por qué funciona ahora? El nombre lo acuñó Seth Larson, desarrollador residente de la Python Software Foundation, en abril de 2025, por analogía con el typosquatting. En lugar de registrar una errata de un paquete popular y esperar a que alguien teclee mal, el atacante registra un nombre que el modelo de IA recomienda con aplomo. La [nota de la Cloud Security Alliance](https://labs.cloudsecurityalliance.org/research/csa-research-note-slopsquatting-ai-supply-chain-20260419-csa/) del 19 de abril de 2026 añade el dato que cambia el cálculo de riesgo: los agentes resuelven dependencias sin que nadie llegue a mirar el nombre del paquete que están instalando. Aspecto Typosquatting Slopsquatting Origen del error La persona teclea mal el nombre El modelo inventa el nombre Defensa habitual Comparar la similitud entre cadenas No sirve, buena parte de los nombres no se parece a nada real Cuándo lo registra el atacante Antes del primer uso accidental Antes del primer uso, tras reproducir los mismos prompts Quién puede reproducirlo Cualquier usuario de un registro Quien ejecute los prompts del modelo que sirve a la víctima La literatura distingue dos errores de fondo. La fabricación pura inventa un nombre que no se parece a nada real. La conflación mezcla dos paquetes auténticos en uno solo, como react-codeshift, que combina jscodeshift con react-codemod. Ese segundo caso se propagó por 237 repositorios de GitHub, según documentó la investigadora Charlie Eriksen, porque vivía dentro de un fichero de instrucciones para agentes que se copió y se bifurcó sin revisión humana. El paquete `unused-imports`, que los modelos confunden con `eslint-plugin-unused-imports`, [sigue registrando descargas semanales](https://www.npmjs.com/package/unused-imports), ya con una retención de seguridad de npm encima. Una orden de instalación copiada por error en la documentación pública de Alibaba acumuló más de 30.000 descargas en tres meses. ## Tres formas de entrar en tu cadena de suministro Los ataques de las últimas semanas se parecen poco entre sí. Uno entró por el repositorio de origen, otro por el flujo de publicación y el tercero por la caché del sistema de integración continua, así que no existe un único punto donde colocar el candado. ### Un preinstall que descarga Bun y llama a casa La versión 0.5.144 del SDK de TypeScript de Tensorlake se publicó en npm el 8 de octubre de 2026 a las 01:12 UTC y desapareció del registro alrededor de las 02:54, una hora y cuarenta minutos después, según el [análisis de Sonatype](https://www.sonatype.com/blog/hijacked-tensorlake-npm-turned-install-into-credential-risk). El paquete, con unas 12.000 descargas semanales, incluía un gancho preinstall que lanzaba un cargador ofuscado llamado setup.mjs. Ese cargador descargaba Bun y ejecutaba un segundo fichero de 856 kilobytes, `Math_Symbol.js`, que iba a por tokens de GitHub y credenciales de HashiCorp Vault. La publicación salió de la propia tubería de GitHub Actions del proyecto y llevaba una atestación Sigstore válida, porque los commits maliciosos habían entrado antes en la rama principal desde una cuenta de administrador. [Endor Labs](https://www.endorlabs.com/learn/tensorlake-npm-package-compromised-by-shai-hulud-in-latest-software-supply-chain-attack) lo formula con precisión: la atestación confirma dónde se construyó el paquete, no que el código sea limpio. El cargador se desactiva si detecta un entorno de integración continua, así que el objetivo eran los portátiles de los desarrolladores. Y escondía una trampa de rehén. Cuando obtenía un token de GitHub, instalaba un vigilante llamado `gh-token-monitor` que consultaba la API cada 60 segundos durante 24 horas. Si el token dejaba de funcionar, borraba el directorio personal de la máquina. Revocar la credencial sin matar antes ese proceso amplifica el desastre en lugar de frenarlo, y conviene decirlo así de claro, porque la reacción instintiva de cualquier equipo es rotar primero y hacer preguntas después. ### Una importación que arranca el implante sin scripts La versión 5.8.3 de @subql/common se publicó el 5 de octubre de 2026 a las 11:56 UTC y estuvo disponible unos 50 minutos, según la [investigación de StepSecurity](https://www.stepsecurity.io/blog/subql-ecosystem-compromised). El atacante no tocó la rama principal, simplemente reescribió el flujo de publicación de SubQuery en una rama desechable. Esa rama descargaba un tarball desde un dominio externo y lo colocaba en lugar del paquete construido, sin comprobar ningún hash. Así, la versión maliciosa salió firmada por el sistema de publicación de confianza del proyecto, indistinguible de una publicación normal. En el paquete había un postinstall y, sobre todo, una ruta que arrancaba el implante al importar la librería. Desactivar los scripts de ciclo de vida no basta aquí, porque un simple require de la dependencia ya inicia el proceso desacoplado. El destino era el dominio `ci-artifacts.dev`, con cifrado híbrido y un canal de órdenes capaz de abrir una shell inversa. StepSecurity contó 19 versiones recientes del ecosistema @subql con un camino posible hacia la versión mala, porque rangos como el tilde de 5.8.2 la aceptaban sin protestar. Aquí aparece el mejor contraejemplo de todo el mes. La versión canaria 5.8.3-onf-rt1 llevaba una atestación SLSA de nivel 1, mientras que la versión limpia 5.8.2 no tenía ninguna. Una política que solo mirase la procedencia habría ordenado al atacante por encima del proyecto legítimo. ### Una caché de GitHub Actions que firma el paquete por ti TanStack es el caso antiguo de esta historia. La tarde del 11 de mayo de 2026, entre las 19:20 y las 19:26 UTC, un atacante publicó 84 versiones maliciosas de 42 paquetes de la familia @tanstack/\*, según [el análisis posterior del propio proyecto](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem). El vector no fue un token de mantenedor robado. Fue la combinación de tres fallos conocidos: el patrón pull\_request\_target que ejecuta código de una bifurcación, el envenenamiento de la caché de GitHub Actions y la extracción en memoria del token OIDC del runner. Un investigador de StepSecurity detectó el paquete malicioso entre 20 y 26 minutos después de la publicación, y aun así la campaña siguió creciendo. La misma operación, bautizada Mini Shai-Hulud, alcanzó más de 170 paquetes y 401 artefactos maliciosos en cinco horas, según [SecurityWeek](https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-in-fresh-supply-chain-attack/). Entre las víctimas estuvieron UiPath, Mistral AI y el cliente JavaScript de OpenSearch. Cinco meses después, el 12 de octubre de 2026, [Security Today](https://securitytoday.com/articles/2026/10/12/what-the-tanstack-attack-taught-us-about-modern-supply-chain-risk.aspx) publicó la retrospectiva de Grafana Labs, una de las empresas afectadas en el mismo episodio. De esa retrospectiva sale la lección más útil de todo el mes. Grafana Labs detectó el movimiento y rotó todas las credenciales que su inteligencia de amenazas señaló, y aun así se le escapó una. La decisión fue añadir una segunda pasada de auditoría al proceso de rotación como paso obligatorio y no opcional. Es un cambio de proceso que no cuesta dinero y que ninguna consola de seguridad vende. ![Infografía de como funciona y afecta el slopsquatting](https://content.observatorioblockchain.com/wp-content/uploads/2026/10/infografia-slopsquatting.webp) *Infografía de como funciona y afecta el slopsquatting* ## ¿Cómo se delata un paquete envenenado? Antes de llegar a la tabla de controles conviene saber qué mirar, porque ninguna de las tres intrusiones dependía de un nombre sospechoso ni de un error humano. Las señales útiles son de comportamiento y de metadatos, y casi todas se pueden revisar sin comprar ninguna licencia. * Un salto de versión de parche que estrena ganchos de instalación. Tensorlake, SubQuery y decenas de casos anteriores añaden preinstall o postinstall en la misma publicación que trae el problema. * Un fichero nuevo y desproporcionado dentro del paquete. El payload de Tensorlake ocupaba 856 kilobytes de JavaScript ofuscado; el de SubQuery escondía 459 cadenas en base64 dentro de un módulo de 62 kilobytes. * Un proceso que no encaja con la instalación. Si aparece bun en una máquina que nunca lo tuvo, o node lanza un script que lee ficheros de credenciales, claves SSH o perfiles de navegador, el daño ya está hecho. * Versiones resueltas por rango. El tilde de 5.8.2 aceptaba la versión envenenada 5.8.3, y el lockfile resolvía a la anterior solo por inercia. * Lógica que se apaga en integración continua. El cargador de Tensorlake terminaba si detectaba un runner, lo que revela a qué equipo apuntaba el ataque. * Un nombre sin historia. En slopsquatting el paquete es reciente, no tiene repositorio detrás y su publicador no registra actividad previa. El orden de comprobación importa más que la lista completa. Si solo vas a mirar dos cosas, mira la fecha de publicación y los cambios en los scripts de instalación, porque juntas cubren el slopsquatting y el secuestro de una versión legítima. ## La tabla de controles que conviene desplegar Los controles se ordenan por lo que cortan y no por lo que cuestan. Casi todos se pueden activar en una tarde y ninguno es suficiente por separado, porque el paquete de SubQuery desactivaba una defensa y el de Tensorlake se saltaba otra. Control Qué corta Dónde se aplica Cuarentena por antigüedad (minimumReleaseAge en pnpm, min-release-age en npm) Versiones recién publicadas: Tensorlake estuvo 1 h 40 min y SubQuery 50 min Resolución local y canalización Instalación sin scripts y aprobación explícita de scripts de dependencia Ganchos preinstall y postinstall Cada instalación y cada runner Lockfile versionado con instalación reproducible desde el fichero Resolución por rangos como el tilde de 5.8.2 Repositorio y canalización Cortafuegos de políticas en el registro, como el que GitLab presentó el 6 de octubre de 2026 Edad mínima, gravedad, licencia y detección de malware, con modo aviso o bloqueo Canalización, empezando en modo aviso Aprobación humana antes de que un agente añada una dependencia Nombres alucinados y órdenes inyectadas en el prompt Entorno del agente Comprobación del nombre en el registro antes de instalar Slopsquatting, sobre todo en nombres nuevos y sin repositorio Editor y revisión de cambios Lista blanca, espejo privado y lista de materiales del software Dependencias fuera de catálogo y rastreo posterior de un incidente Registro y canalización Tokens efímeros con permisos mínimos y canalización compartimentada Alcance del robo cuando el paquete ya se ha ejecutado Integración continua y nube Rotación con segunda pasada de verificación Credenciales que sobreviven al primer barrido Respuesta a incidentes Detección de comportamiento en la instalación Payloads que no aparecen en ningún aviso de vulnerabilidad Registro y agente local La propia GitLab documenta por qué el modo aviso va primero: bloquear desde el día uno empuja a los equipos a desactivar el control para poder trabajar. En junio de 2026, sus investigadores encontraron cinco paquetes maliciosos en PyPI. Cuatro de ellos eran suplantaciones de Flask, Requests y NumPy que robaban credenciales de la canalización en el momento de la instalación. Palo Alto Networks añadió el 7 de octubre de 2026 el argumento de escala con [su nota sobre código abierto y modelos de frontera](https://www.paloaltonetworks.com/blog/cloud-security/securing-open-source-software-in-the-frontier-ai-era/). Su sistema agéntico NOVA identificó más de 14.000 vulnerabilidades confirmadas en 3.915 proyectos durante dos meses. El 99,4% no tenía aviso previo y el 40% restante alcanzaba gravedad alta o crítica, de modo que revisar el inventario de dependencias una vez al año deja de tener sentido. ## ¿Basta con que el paquete esté firmado? No, y conviene entender por qué. Los tres incidentes de 2026 comparten un rasgo que desarma la intuición más extendida: la firma y la atestación eran auténticas. Tensorlake publicó desde su propio flujo de trabajo con procedencia Sigstore válida porque el código malicioso entró antes, en la rama principal. SubQuery publicó a través de su sistema de publicación de confianza, no con una contraseña robada a un mantenedor. Y TanStack firmó 84 versiones maliciosas con una identidad de compilación legítima que el atacante había secuestrado. La procedencia responde a una pregunta concreta: qué repositorio, qué commit y qué flujo produjeron el artefacto. No responde si ese código debería existir, ni si la versión cambió algo raro respecto a la anterior. Por eso la política útil no pregunta si hay firma, sino qué cambió en el paquete, cuánto tiempo lleva publicado y si el publicador tiene historial verificable. Una regla de edad mínima de 24 horas habría dejado fuera los dos paquetes de octubre sin analizar una sola línea de código. ## Si ya se instaló, el orden de los primeros pasos 1. Mata el vigilante antes de revocar. En el caso de Tensorlake, revocar el token de GitHub disparaba el borrado del directorio personal, así que lo primero es detener gh-token-monitor. 2. Aísla la máquina o el runner y guarda evidencias. Ni el proceso desacoplado ni el implante desaparecen por desinstalar el paquete del árbol de dependencias. 3. Fija la última versión limpia y limpia las cachés. Tensorlake 0.5.143 y @subql/common 5.8.2 son las referencias conocidas, y conviene borrar las entradas del lockfile que apunten a la versión mala. 4. Rota desde una máquina limpia. Tokens de npm y GitHub, credenciales de AWS, Kubernetes y Vault, claves SSH, configuraciones de asistentes y carteras cripto. 5. Rastrea los indicadores concretos. La rama dependabot/github\_actions/format/setup-formatter, el flujo .github/workflows/codeql\_analysis.yml, cada caso es distinto, así que toca analizar y auditar todo. 6. Verifica la rotación con una segunda pasada. Es el paso que Grafana Labs convirtió en obligatorio después de fallar en el primer intento sobre un conjunto de miles de credenciales. 7. Revisa el alcance por dependencias transitivas. Un paquete padre fijado no fija automáticamente a sus hijos, y los rangos con tilde fueron los que dejaron entrar las versiones maliciosas. El último punto merece énfasis porque es contraintuitivo. Fijar @subql/cli en su última versión no protegía de la 5.8.3, ya que el rango de su dependencia interna la admitía. La auditoría tiene que mirar el árbol resuelto por el gestor de paquetes. ## El reloj regulatorio ya está corriendo Las obligaciones de notificación del [Reglamento Europeo de Ciberresiliencia](https://eur-lex.europa.eu/ES/legal-content/summary/the-eu-cybersecurity-act.html) entraron en vigor el 11 de septiembre de 2026. Desde esa fecha, los fabricantes de productos con elementos digitales deben avisar de vulnerabilidades explotadas activamente e incidentes graves en un plazo de 24 horas. La notificación completa llega después, con 72 horas de margen, y el caso se cierra con un informe final a través de la plataforma única que gestiona [ENISA](https://www.enisa.europa.eu/news/the-cra-single-reporting-platform-is-launched). Los plazos se cuentan desde que el fabricante conoce el problema, no desde que lo arregla. Ese calendario explica por qué el inventario de componentes dejó de ser una buena práctica y pasó a ser un requisito operativo. Sin una lista de materiales de software actualizada no hay forma de determinar en horas si un paquete comprometido entró en un producto. Los administradores de código abierto quedan sujetos a las mismas obligaciones desde el 11 de diciembre de 2027, la fecha en la que además se aplican los requisitos principales del reglamento. Hasta entonces, el reloj solo corre para quien fabrica. ## Una superficie que crece más rápido que los controles La conclusión razonable no es dejar de usar asistentes ni confiar solo en firmas. Es aceptar que la lista de dependencias se ha convertido en una superficie de ataque con dos motores nuevos: un modelo que propone nombres que no existen y un agente que los instala sin consultar a nadie. Los ataques de octubre de 2026 no necesitaron ninguna de esas dos piezas para hacer daño, y esa distancia mide bien el problema al que se enfrenta cualquier equipo que hoy entrega software varias veces al día. Queda una pregunta abierta y honesta. Hasta mediados de 2026 no consta públicamente ninguna brecha atribuida a un paquete registrado sobre un nombre alucinado, solo nombres vivos y descargas contadas en los registros públicos. Las campañas que secuestran versiones legítimas sí tienen víctimas confirmadas, así que la prioridad sensata es tapar primero la vía que ya está demostrada. La vigilancia de nombres alucinados queda como segunda capa, con la esperanza de que nunca llegue a ser la primera.