¿Qué es el «slopsquatting»? Cómo las alucinaciones de los paquetes de IA se convierten en ataques a la cadena de suministro

Principales conclusiones

• El «slopsquatting» consiste en que un atacante registra el nombre de un paquete inventado por una herramienta de IA y espera a que alguien lo instale.
• Funciona porque las alucinaciones se repiten, y el 43 % volvió a aparecer en las diez repeticiones del estudio de USENIX.
• Un repositorio que rechaza cualquier elemento que no figure en un catálogo aprobado impide por completo que se resuelva un nombre inventado.
• Los agentes de programación que instalan las dependencias por sí mismos eliminan el último control manual.

Alguien de tu equipo pega un fragmento de código de Python procedente de un asistente de IA y ejecuta el comando línea «pip install» que venía con él, y la terminal se desplaza sin mostrar ningún error. La importación funciona. El «slopsquatting» es lo que ocurre cuando el nombre de ese paquete no apuntaba a nada hasta que un atacante se hizo con él. El modelo lo inventó, alguien lo registró primero y la instalación le proporcionó un punto de apoyo.

Esta guía explica qué es el «slopsquatting», cómo se desarrolla la cadena de ataque, qué revelan realmente los estudios sobre la frecuencia con la que se produce y qué medidas de defensa resultan eficaces antes de que llegue a una tubería real.

¿Qué es el «slopsquatting»?

El «slopsquatting» es un ataque a la cadena de suministro de software en el que un atacante registra un nombre de paquete que suele provocar «alucinaciones» en los grandes modelos de lenguaje y, a continuación, publica código malicioso bajo ese nombre. El desarrollador lo instala porque su asistente de IA le ha dicho que existe. Eso es una «alucinación de paquete»: el modelo recomienda una dependencia que no se encuentra en el registro al que acaba de remitirte.

El término fue acuñado por Seth Larson, desarrollador residente especializado en seguridad de la Python Software Foundation, y se popularizó gracias a Andrew Nesbitt, que dirige la plataforma de datos de código abierto Ecosyste.ms. Añade «AI slop» a «typosquatting». 

Aquí nadie se ha equivocado al escribir nada. El comando de instalación era correcto, el nombre estaba escrito exactamente como lo había indicado el modelo, y la confianza en él provenía de un sistema que nunca verificó el nombre con el registro del que procedía la recomendación.

«Slopsquatting» frente a «typosquatting»

El «typosquatting» se aprovecha de los errores humanos. solicitudes en lugar de solicitudes. O python3-dateutil, subido a PyPI en 2019 para hacer competencia a python-dateutil y eliminado días después, cuando alguien se dio cuenta de que incorporaba un segundo paquete que recopilaba claves SSH y GPG. El «slopsquatting» se aprovecha de los errores de los sistemas, y resulta que estos errores están mucho mejor organizados.

	Typosquatting	Sentadillas con peso
¿Qué activa la instalación?	¿Un error humano o un nombre mal recordado?	Una IA recomienda un nombre que no figura en el registro correspondiente
Escala observada en un estudio	Agrupados en torno a un puñado de objetivos de gran valor	Se han observado 205.474 nombres alucinados distintos
Previsibilidad	El atacante adivina los posibles errores ortográficos	El atacante recopila nombres mediante el entrenamiento de modelos
Similitud con nombres reales	Normalmente, basta con un pequeño retoque para que se parezca a la realidad	El 13,4 % de las «alucinaciones» de Python se encuentran a una distancia de edición de 1 a 2 del paquete real más cercano; el 48,6 % se encuentran a seis ediciones o más de distancia.
¿Quiénes corren riesgo?	Desarrolladores y flujos de trabajo automatizados que corrigen un nombre erróneo	Cualquiera que acepte listas de dependencias generadas por IA, incluidos los agentes

Muchos de los nombres inventados no se parecen en nada a un paquete real. Solo el 13,4 % de los nombres inventados en Python se encontraban a uno o dos caracteres del nombre existente más cercano, mientras que el 48,6 % estaban a seis modificaciones o más de distancia. Se trata de inventos que suenan plausibles, más que de nombres que se parecen mucho, y por eso las comprobaciones de distancia de edición y de similitud de nombres pasan por alto tantos de ellos.

Los nombres también se repiten. Los investigadores de USENIX tomaron 500 indicaciones que habían generado alucinaciones y volvieron a ejecutar cada una de ellas diez veces. El 43 % de los nombres alucinados aparecieron en las diez ejecuciones, y el 58 % aparecieron más de una vez. Un atacante no tiene que adivinar. Esa recurrencia es lo que realmente lo diferencia del «typosquatting» clásico, en el que el atacante predice cómo cometen errores los humanos al escribir, en lugar de medir lo que un modelo inventa de forma fiable.

Cómo funciona un ataque de tipo «slopsquatting»

Cuatro pasos, ninguno de ellos técnicamente complejo, lo que explica en parte por qué los paquetes generados por la IA constituyen un mecanismo de distribución tan eficaz. Un intento exitoso se corresponde con MITRE ATT&CK T1195.001, «Compromiso de dependencias de software y herramientas de desarrollo», por lo que encaja dentro de un modelo de amenazas que ya conoces, en lugar de quedar al margen como algo exótico.

1. Recoger las alucinaciones

El atacante ejecuta a gran escala solicitudes de generación de código, recopila todos los nombres de paquetes que aparecen en el resultado y comprueba cada uno de ellos en PyPI o npm. Los nombres que no se resuelven se añaden a la lista. Los nombres que siguen sin resolverse, tras repetidas ejecuciones del mismo modelo, pasan a la parte superior de la lista.

Hay un hallazgo que merece la pena analizar con detenimiento. En el estudio de USENIX, los nombres alucinados eran, con mucha más frecuencia, específicos de un solo modelo que comunes a varios: el 81 % de los nombres únicos procedían exactamente de uno de los 16 modelos analizados. La recurrencia y el solapamiento varían según el modelo, por lo que lo más sensato es evaluar los asistentes que utiliza realmente tu propio equipo, en lugar de dar por sentado que una lista negra común te cubre las espaldas.

Las mediciones a escala de investigación no son baratas, pero tampoco tienen por qué serlo. El equipo de USENIX generó 576 000 ejemplos de código en 16 modelos para abarcar dos lenguajes y un amplio conjunto de indicaciones. El volumen necesario para analizar un marco de trabajo, un SDK en la nube o un caso de uso de carácter interno es un problema distinto y mucho menor.

La elección del modelo tuvo una gran importancia en los modelos que se evaluaron en el estudio a principios de 2024, en el que los modelos de código abierto presentaban un porcentaje medio de «alucinaciones» del 21,7 %, frente al 5,2 % de los modelos comerciales. Un preimpresión de 2026 que aplica la misma metodología a cinco modelos de vanguardia más recientes reveló que las tasas generales oscilaban entre el 4,62 % y el 6,10 %. No ha sido sometida a revisión por pares, por lo que debe considerarse una señal preliminar más que una tendencia consolidada. En cualquier caso, los nombres inventados no han desaparecido.

Consejo de experto: Sufijos plausibles como -utils, -helpers, -client, y -sdk pueden hacer que un nombre inventado parezca creíble a primera vista. Considera una convención de nomenclatura que parezca sensata como un motivo para comprobarlo, nunca como una prueba de que un paquete sea real.

2. Registra el nombre y haz que parezca vivo

El atacante registra los mejores nombres y publica algo que funciona: código funcional que hace más o menos lo que sugiere el nombre, un archivo README y una licencia que se lee con normalidad.

La carga útil se encuentra en la ruta de instalación o en una importación que casi nadie utiliza. Un gancho de instalación que realiza una solicitud saliente cuando se ejecuta, o código que se comporta de una forma en un ordenador portátil y de otra en un entorno con credenciales y acceso a la red que vale la pena tener. Una funcionalidad de aspecto inofensivo permite ganar tiempo precisamente porque la importación esperada parece funcionar.

Las cifras de descargas lo dejan más claro que cualquier hipótesis. Lasso Security registró un paquete vacío con el nombre inventado «huggingface-cli» y registró más de 30 000 descargas en tres meses, incluido un repositorio de investigación de Alibaba cuyo archivo README indicaba a los usuarios que lo instalaran. Una prueba de concepto inofensiva, sin ningún tipo de carga útil, acabó siendo referenciada en artefactos de desarrollo reales.

3. Un desarrollador lo instala siguiendo las instrucciones de la IA

La instalación en sí no tiene nada de especial. Alguien le pregunta a un asistente cómo hacer algo, obtiene un código que parece que funciona y ejecuta el comando que viene con él.

pip install NOMBRE_DEL_PAQUETE

A falta de controles del registro o de alertas en los puntos finales, no se activa ninguna advertencia. El paquete se resuelve, se instala y se importa. Si el desarrollador comprueba algo, se limita a comprobar que la importación funciona, y así es.

La confianza en el modelo se traslada aquí. El nombre de un paquete que se encuentra dentro de un código por lo demás correcto se beneficia de la credibilidad de ese código, y en un equipo que trabaja a un ritmo acelerado, una nueva dependencia introducida en un cambio que, por lo demás, es rutinario, recibe menos atención que la lógica que la rodea, a menos que la revisión ponga de manifiesto explícitamente las adiciones de dependencias. Una persona sigue teniendo que leer la sugerencia y decidir si la ejecuta. Cuando se permite que un agente instale dependencias y no hay ningún filtro de aprobación que lo impida, nadie lo lee en absoluto.

4. Se mantiene en todas las compilaciones y en la integración continua

Una vez que el nombre figure en requirements.txt o package.json, deja de ser una decisión y se convierte en infraestructura. Las compilaciones que se instalan a partir de ese manifiesto lo incorporan. Las nuevas imágenes de contenedor lo integran. Todos los entornos que resuelven la dependencia lo heredan, desde ordenadores portátiles hasta ejecutores de CI, pasando por sistemas de compilación que contienen tokens de implementación y credenciales de registro.

La propagación transitiva agrava aún más la situación. Si el paquete comprometido se incorpora como dependencia de una biblioteca interna, llega a servicios cuyos responsables nunca vieron la sugerencia original. En ese momento, la cuestión de la auditoría ya no es quién lo instaló, sino dónde ha acabado.

A partir de ahí, las consecuencias son las habituales en cualquier caso de vulneración de una dependencia: robo de credenciales, minería de criptomonedas, tráfico saliente inesperado o una vulneración más amplia de todo aquello a lo que pueda acceder el entorno de compilación, incluidos los servidores Linux.

Atención: Los archivos de bloqueo identifican el paquete malicioso con la misma precisión que uno legítimo. Un archivo de bloqueo garantiza la reproducibilidad; no dice nada sobre lo que se ha bloqueado. Reproducirá la infección en cada equipo que lo instale hasta que la dependencia y su entrada en el archivo de bloqueo se eliminen deliberadamente.

Lo que revelan los estudios

Estas cifras proceden de «¡Tenemos un paquete para ti! Un análisis exhaustivo de las alucinaciones sobre paquetes generadas por modelos de lenguaje grande (LLM) generadores de código», presentado en USENIX Security 2025. Se trata del estudio a gran escala que acaba citando todo el mundo en este ámbito, y cada cifra de la tabla que aparece a continuación procede directamente de él, en lugar de un resumen de segunda mano.

Conclusión	Figura
Recomendaciones de paquetes alucinantes	440 445 de 2,23 millones (19,7 %)
Nombres singulares fruto de alucinaciones observados	205,474
Tasa de alucinaciones en los modelos de código abierto	21.7%
Tasa de alucinaciones en modelos comerciales	5.2%
Las alucinaciones se repitieron en las 10 reposiciones	43%
Alucinaciones que nunca se repitieron	39%
Alucinaciones de Python válidas como paquetes de npm	8.7%

Hay tres aspectos que son más importantes que el porcentaje que aparece en el titular.

La recurrencia es lo que facilita el ataque. El 43 % de los nombres alucinados reaparecieron en las diez repeticiones y el 58 % reapareció más de una vez, lo que sitúa a la mayor parte de ellos fuera del ámbito del ruido puntual. La repetibilidad es lo que hace que la recolección merezca la pena para un atacante.

La cifra relativa a los ecosistemas cruzados es la que confunde a la gente. El 8,7 % de los nombres de Python inventados eran paquetes válidos de npm, por lo que un desarrollador que compruebe si un nombre existe en algún sitio recibe una respuesta positiva que no significa nada. El hecho de que exista en otro registro no es prueba de que sea la dependencia que has solicitado.

La diferencia entre lenguajes cambia. En los modelos de la época de 2024 del estudio de USENIX, JavaScript presentaba un 21,3 % de «alucinaciones», frente al 15,8 % de Python. El preprint de 2026 indicaba que esa relación se invertía en sus cinco modelos más recientes. Considéralo una característica del modelo concreto que tengas delante, más que del lenguaje en sí.

Por qué los agentes de IA aumentan lo que está en juego

 

El paso 3 anterior parte de la base de que alguien lee una sugerencia de código generada por IA antes de ejecutarla. Las herramientas basadas en agentes pueden eliminar esa suposición. Un agente que detecta un error, determina que falta una dependencia y la instala ha cerrado el ciclo; y, sin necesidad de una vista previa, una comprobación de políticas ni un proceso de aprobación, el nombre del paquete llega al disco antes de que nadie lo vea.

Las pruebas realizadas por los proveedores indican que las herramientas están mejorando, aunque sin resolver el problema. La investigación de Trend Micro sobre el «slopsquatting» reveló que los agentes de codificación con razonamiento de cadena de pensamiento y búsqueda web en tiempo real redujeron las tasas de alucinaciones aproximadamente a la mitad en su evaluación, siendo las configuraciones que realizaban validación en tiempo real las que generaban el menor número de dependencias fantasma de todas. Aun así, algunos nombres lograron colarse. Trend Micro atribuye los errores residuales al relleno de lagunas contextuales, la imitación de la forma superficial y el préstamo de nombres entre ecosistemas, en los que el agente ensambla algo que sigue las convenciones de los paquetes reales sin corresponder a ninguno de ellos.

Una reducción del 50 % es significativa. No es un control que se pueda entregar a un auditor.

Luego está la «codificación por intuición», que en este contexto significa aceptar rápidamente el código generado por la IA sin revisar de forma independiente sus dependencias ni lo que estas hacen al instalarse. La opción por defecto más segura es la contraria. Cualquier dependencia de terceros sugerida por la IA permanece sin verificar hasta que algo distinto al modelo confirme el paquete y la versión. Si a esa laguna se suman los agentes que se instalan por su cuenta, el punto de control de revisión deja de existir.

Cómo defenderse del «slopsquatting»

No hay un único control que lo detecte. La verificación detecta los casos evidentes, la fijación de límites restringe el alcance del impacto, una lista de permisos obligatoria cierra la vía de resolución, y la política de análisis y revisión garantiza que los tres primeros se apliquen correctamente. Utilízalos todos juntos.

Si tus compilaciones se resuelven directamente desde registros públicos, la lista de permitidos de la medida de defensa n.º 3 es la que cambia la naturaleza del problema. Si ya utilizas un espejo interno, comprueba primero si aplica una lista de permitidos o si simplemente almacena en caché todo lo que se le envía, ya que una caché de transferencia sin restricciones deja esta vulnerabilidad prácticamente igual que antes.

1. Comprueba que el paquete existe y que tiene un historial

Antes de que un paquete sugerido por la IA se incluya en un manifiesto, comprueba cuándo se publicó por primera vez, quién se encarga de su mantenimiento, si el repositorio al que pertenece es real y está activo, y si el artefacto del registro se corresponde con esa fuente. Los datos sobre la publicación y el responsable del mantenimiento proceden directamente de los metadatos del registro, sin necesidad de instalar nada ni de ejecutar el código del paquete.

curl -s https://pypi.org/pypi/PACKAGE_NAME/json

npm view NOMBRE_DEL_PAQUETE time.created maintainers

La adopción es una consulta independiente. El punto final JSON de PyPI devuelve -1 en sus campos de descargas, así que obtén ese dato de pypistats o del conjunto de datos de BigQuery si el volumen de descargas forma parte de tu gráfico de barras. La autenticidad del repositorio y la correspondencia entre el código fuente y el artefacto también requieren su propia verificación; un enlace al registro por sí solo no prueba nada sobre quién es el propietario de aquello a lo que apunta.

Establece los criterios como política, no como instinto. Edad, adopción, identidad del mantenedor y coincidencia verificada entre el código fuente y el artefacto. Estos cuatro aspectos pondrán de manifiesto las inconsistencias evidentes antes de que una dependencia entre en el gráfico; sin embargo, un paquete malicioso bien elaborado aún puede superar todos ellos. Son señales que deben tenerse en cuenta en la revisión, no una garantía de seguridad.

2. Fijar las dependencias mediante archivos de bloqueo y hash

Los archivos de bloqueo garantizan la reproducibilidad. Los hash garantizan la integridad: siempre que el hash se haya obtenido y protegido mediante un proceso en el que confíes, confirman que el artefacto que has instalado es el mismo que aprobaste.

pip install –require-hashes -r requirements.txt

El modo de comprobación de hash es de todo o nada. Cada requisito y cada dependencia transitiva deben fijarse con == y llevar un hash, o la instalación fallará rotundamente, así que hay que contar con que la primera pasada será una tarea ardua. Lo que la fijación no hace es indicarte que lo que has fijado haya sido seguro en algún momento. Los datos del registro de npm son inmutables, por lo que un nombre y una versión determinados no pueden volver a publicarse ni siquiera tras una retirada; el fallo más probable es aprobar y congelar el paquete equivocado desde el primer día, por lo que la fijación debe realizarse tras la verificación y no en su lugar.

La ejecución de scripts durante la instalación es una palanca independiente, y npm ya la ha activado. La versión actual de npm bloquea por defecto los scripts de instalación de dependencias, omitiendo los scripts de ciclo de vida para cualquier elemento que no tenga una entrada correspondiente en allowScripts y mostrando al final de la instalación la lista de los que se han omitido. npm install-scripts approve y npm install-scripts deny mantén esa lista, con las aprobaciones vinculadas a la versión que realmente has revisado.

npm ci –ignore-scripts

En versiones antiguas de npm, esa opción es la versión simplificada de la misma idea, sin la lista de permitidos. En cualquier caso, solo afecta al momento de la instalación. El código que se ejecuta al importar, al compilar o en tiempo de ejecución no se ve afectado.

3. Obtén información únicamente de fuentes seleccionadas

La medida estructural más contundente consiste en modificar a qué puede resolverse un nombre. Un repositorio que rechace cualquier elemento ajeno a un catálogo autorizado fallará al resolver un nombre inventado, lo cual supone el punto más económico de toda la cadena en el que puede producirse un fallo.

Esa propiedad proviene de la lista de permitidos, no del repositorio que se está gestionando. Hay muchos registros privados que ofrecen versiones verificadas de los paquetes que incluyen y redirigen todo lo demás desde la fuente original, lo que deja intacta la exposición original para cualquier nombre que no forme parte del conjunto cubierto. Vale la pena comprobarlo antes de dar por hecho que un espejo ha cerrado sus puertas.

SecureChain de TuxCare está diseñado para el conjunto de tecnologías cubiertas. Abarca seis ecosistemas —JavaScript, Python, Java, Go, Rust y PHP—, todos ellos disponibles en el mismo catálogo seleccionado. Los plazos de lanzamiento varían ligeramente según el ecosistema y es posible que uno o varios de ellos aún se encuentren en fase de prelanzamiento, por lo que, si necesitas información actualizada sobre el estado de una pila concreta, envía un correo electrónico a [email protected].

Los paquetes se vuelven a compilar a partir del código fuente en entornos aislados y reforzados, se analizan en busca de malware conocido y patrones de código sospechosos, y se actualizan conforme al SLA a medida que se publican los CVE, con procedencia de nivel 3 según SLSA y datos SBOM y VEX disponibles. Dirige tu gestor de paquetes o repositorios al registro de TuxCare y el archivo de bloqueo regenerado registrará las URL y las sumas de comprobación de TuxCare en lugar de los archivos tar públicos. Según la propia documentación de TuxCare, ese registro ofrece compilaciones de SecureChain cuando existen y paquetes públicos de origen para el resto a través del mismo punto final, por lo que la garantía contra el «slopsquatting» proviene de la lista de permitidos que se aplica sobre ella, no solo del cambio de registro.

4. Analizar y observar el comportamiento de las nuevas dependencias

El análisis de firmas y de reputación funciona mejor contra amenazas que ya han sido identificadas. Un paquete malicioso recién registrado aún no ha llegado a esas bases de datos, y ese es precisamente el margen de maniobra que aprovecha el «slopsquatting».

Las comprobaciones de comportamiento cubren esa laguna. Accesos inesperados a la red durante la instalación, código fuente ofuscado o minificado en un paquete que debería estar en formato plano, lecturas de credenciales y variables de entorno, y escrituras fuera del directorio del paquete. Hay muchos paquetes legítimos que realizan una o dos de estas acciones, especialmente las compilaciones de módulos nativos, por lo que la tarea consiste en detectarlas para su revisión, en lugar de bloquearlas automáticamente.

Analiza los cambios en las dependencias en la integración continua (CI) antes de que se fusionen y, además, mantén en marcha un análisis programado. El primero detecta lo que estás añadiendo; el segundo detecta el paquete que funcionaba correctamente cuando se incorporó y dejó de hacerlo tres semanas después.

Consejo de experto: Aplica el control de versiones al manifiesto de dependencias en cada solicitud de incorporación de cambios y exige una aprobación explícita de las incorporaciones, al margen de la revisión del código. Separar los cambios en las dependencias de los cambios generales en el código es lo que hace que la revisión de la cadena de suministro sea lo suficientemente visible como para insistir en ella.

5. Redactar una política de revisión para el código generado por IA

Las herramientas no solucionan las deficiencias de un proceso. Decide, por escrito, qué ocurre cuando una herramienta de IA propone una dependencia.

Una política viable considera que cualquier paquete sugerido por la IA no es de confianza hasta que una persona lo haya sometido a las comprobaciones de la defensa 1, y aprueba las nuevas dependencias por nombre y versión, en lugar de basarse únicamente en que la compilación haya dado resultado positivo. Los agentes no obtienen acceso de escritura sin revisar a los manifiestos de dependencias; las adiciones y los cambios de versión pasan por un proceso de aprobación. La lista de fuentes aprobadas se aplica en el gestor de paquetes o en la capa de políticas del repositorio, de modo que un incumplimiento de la política se manifiesta como un fallo de compilación en lugar de como un problema de confianza.

Qué cambia TuxCare SecureChain en lo que instalas

El «slopsquatting» funciona porque un comando de instalación resuelve sin problemas un nombre que nadie ha comprobado. SecureChain cambia el resultado que se obtiene al resolverlo. Los paquetes del catálogo se recompilan a partir de código fuente verificado y se analizan en busca de malware conocido y patrones sospechosos antes de que estén disponibles para su instalación, y se siguen actualizando incluso después de que los mantenedores originales hayan dejado el proyecto, lo que resuelve el problema de las dependencias comprometidas, que va de la mano del de los nombres inventados.

Aplica una lista de permitidos en la parte superior, de modo que la compilación no pueda ir más allá de ese catálogo y un nombre inventado no tenga nada desde lo que instalarse, independientemente de si un atacante ha llegado allí primero o no.

Descubre cómo se integra en tu entorno en la página de SecureChain para OSS, o plantéanos una pregunta sobre tu entorno concreto.

Preguntas frecuentes