Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Tanto los errores tipográficos como las «alucinaciones» de la IA proporcionan a los atacantes un nombre de paquete válido, y en ninguno de los dos casos se necesita un exploit.
- La procedencia demuestra de dónde procede un objeto, pero no que la transacción o la cuenta que hay detrás sean legítimas.
- Prestar atención no es una solución escalable, así que centra el trabajo en las dependencias fijas, el enrutamiento determinista y las listas de permisos de scripts.
¿Te has parado a pensar alguna vez en la longitud de la cadena de personas en las que confías cada vez que instalas un paquete? La persona que escribió el código. La persona que revisó el código. El registro que lo aloja. El ejecutor de CI que lo descarga a las 3 de la madrugada sin que nadie lo supervise. Los atacantes son expertos en husmear en los ecosistemas de paquetes y se han vuelto muy hábiles a la hora de encontrar el eslabón más débil de esa cadena. Instalar código más rápido de lo que nadie puede revisarlo conlleva un sinfín de problemas.
La mayoría de los ataques a la cadena de suministro de software funcionan así. No necesitan traspasar el perímetro; utilizan una vía de confianza tal y como fue diseñada para ser utilizada.
A continuación te ofrecemos un breve resumen de las formas en que se abusa de la confianza y de lo que realmente ayuda.
Errores tipográficos en los paquetes
El truco más antiguo que no requiere ningún exploit. Solo hace falta que escribas rápido y no te fijes demasiado. Un atacante publica un paquete con una letra o un guion de más y espera a que alguien lo instale por error.
En crossenv El paquete es un ejemplo muy conocido. En julio de 2017, un usuario de npm conocido como hacktask publicó unos 40 paquetes muy parecidos; el más destacado fue cross-env sin el guion. Si te saltabas ese carácter, lo que habías instalado leía tus variables de entorno y las enviaba a un servidor controlado por el atacante.
{
"name": "crossenv",
"scripts": {
"postinstall": "node package-setup.js"
}
}Informe de incidencias de npm indica el nombre del script de carga útil package-setup.js. En pocas palabras, hacía lo siguiente:
// Simplified illustration of what the script did.
// Reads the environment variables available to the
// install, then sends them to the attacker's server.
const vars = process.env;
sendToAttackerServer(vars);En un equipo de desarrollo o en un servidor de integración continua, esas variables suelen contener tokens de registro, credenciales de la nube y contraseñas de bases de datos, por lo que merece la pena aprovecharlas. npm registró 679 descargas de crossenv pero se calculaba que no más de unas 50 eran instalaciones reales y no réplicas.
La razón por la que el «typosquatting» funciona es que la solución no consiste en aplicar un parche. La verdadera «solución» pasa por prestar atención, y todos sabemos que prestar atención no es algo que se pueda hacer a gran escala. Así que traslada el trabajo a un lugar donde sí sea posible: fija las dependencias, revisa los cambios en el archivo de bloqueo con el mismo cuidado que los cambios en el código y resuelve los problemas a partir de una fuente interna aprobada.
Sentadillas con IA (Slopsquatting)
El «slopsquatting» es el mismo truco que se aprovecha de un error diferente. En lugar de un error tipográfico, se basa en que un asistente de programación recomiende un paquete que no existe, lo que brinda al atacante la oportunidad de registrar ese nombre antes de que lo haga un proyecto real.
En el estudio «USENIX Security 2025» sobre «alucinaciones de paquetes», 16 modelos generaron 576 000 muestras de código que hacían referencia a 2,23 millones de paquetes. En el conjunto de esas pruebas, el 19,7 % de las referencias —440 445 en total— mencionaban paquetes que no existen, lo que abarca 205 474 nombres inventados únicos. Cuando los investigadores volvieron a ejecutar las solicitudes que ya habían producido una «alucinación», el 43 % de los nombres inventados reaparecieron en las diez ejecuciones, lo que justifica su registro previo.
El caso de «huggingface-cli» es un buen ejemplo. El investigador de seguridad Bar Lanyado, de Lasso Security, se dio cuenta de que los modelos recomendaban ese nombre a pesar de que no existía ningún paquete con ese nombre en PyPI, por lo que, en diciembre de 2023, registró uno vacío. Este acumuló más de 30 000 descargas auténticas en tres meses, y el comando de instalación erróneo apareció en el archivo README de un repositorio público de investigación de Alibaba.
# What an AI assistant might confidently suggest
pip install huggingface-cli
# What actually installs the official Hugging Face CLI
pip install -U "huggingface_hub[cli]"La segunda instala la versión oficial huggingface_hub paquete con su complemento CLI. El primero instala cualquier distribución que esté registrada bajo un nombre inventado por un modelo. El de Lanyado era inofensivo a propósito. El de otra persona no tendría por qué serlo. Así que confirma que el proyecto existe, comprueba quién es el editor y el historial de versiones, y haz que se apruebe antes de que llegue a un archivo de bloqueo.
Confusión de dependencias
La confusión de dependencias es un error de resolución. Se produce cuando una empresa utiliza paquetes privados junto con paquetes públicos y la compilación puede resolver un nombre a partir de más de una fuente.
Los detalles varían según el ecosistema. pip es el ejemplo más claro: hay que añadirle un índice adicional con --extra-index-url y tiene en cuenta los candidatos de todos los índices configurados, para luego seleccionar la mejor coincidencia entre todos ellos, lo que puede significar que prevalezca un paquete público de una versión superior. npm resuelve por ámbito y por registro configurado, en lugar de fusionar fuentes, por lo que la exposición en ese caso suele deberse a un nombre interno sin ámbito, o a un proxy que combina lo público y lo privado en una única vista sin que haya detrás una política de espacios de nombres o de prioridades.
Alex Birsan demostró la existencia de este problema en 2020 y 2021 tras descubrir que los nombres de paquetes internos se filtraban a repositorios públicos y a mensajes de error. Publicó paquetes inofensivos con esos nombres en npm, PyPI y RubyGems, con números de versión muy elevados, y observó cómo se incorporaban a las compilaciones internas de más de 35 empresas, entre ellas Apple, Microsoft y PayPal, lo que le reportó más de 130 000 dólares en recompensas por errores.
{
"name": "internal-auth-tool",
"version": "99.0.0"
}Lo peligroso no es el JSON. Es una compilación cuya configuración nunca vincula ese nombre a una fuente de confianza. En el caso de npm, limita el alcance a los paquetes internos y fija ese alcance al registro privado.
# .npmrc
registry=https://registry.npmjs.org/
@your-org:registry=https://your-private-registry.example.com/Ese patrón es específico de npm y solo se cumple cuando coinciden el enrutamiento del registro, la propiedad del espacio de nombres y los permisos de publicación. Los ecosistemas sin ámbitos necesitan su propio sistema de fijación de fuentes; en el caso de pip, eso significa no tratar --extra-index-url como alternativa en la que se da prioridad a lo privado.
Responsables secuestrados
En este caso, se acabaron los trucos y las artimañas. Un atacante se hace con el control de la cuenta o del proceso de lanzamiento asociado a un paquete en el que ya confías y distribuye una actualización maliciosa a través de la infraestructura habitual de lanzamiento del proyecto. Se trata de un abuso de confianza, no de un exploit de código.
El 4 de agosto de 2026, eso fue lo que le ocurrió a keyv y el resto de su familia de almacenamiento en caché. Los atacantes comprometieron la cuenta de GitHub del responsable del mantenimiento, subieron commits maliciosos a la rama principal y dejaron que el propio flujo de trabajo de Actions del proyecto lo compilara y publicara. El gusano, apodado ChainDrop, recopiló todas las credenciales que expusieron los entornos comprometidos y, a continuación, utilizó tokens de npm robados para volver a publicarse en los paquetes de otros responsables de mantenimiento. StepSecurity contabilizó 444 paquetes y 2.212 versiones maliciosas en un plazo de cuatro horas; otros registraron cifras más elevadas más tarde.
Las versiones contaminadas contaban con una procedencia válida, y eso no constituía un fallo de procedencia. Demostraba, correctamente, que el artefacto se había creado mediante el propio flujo de trabajo del proyecto a partir de los datos de entrada declarados. Lo que no puede indicar es si la confirmación introducida era legítima, ni si la cuenta que la realizó seguía perteneciendo a su propietario.
Muchos equipos nunca tuvieron que elegir keyv en absoluto. flat-cache y file-entry-cache se incluyen en ESLint, y keyv se encuentra debajo de esas.
Scripts de preinstalación y postinstalación
Los scripts de instalación no constituyen tanto una categoría de ataque independiente como la vía de ejecución que utilizan varias de las demás. Un paquete puede declarar preinstall, installo postinstall funcionaba, y, históricamente, eso se ejecutaba durante la instalación, antes de que nadie hubiera leído ni una sola línea del código.
Ese momento es clave. El script se ejecuta con los privilegios del desarrollador o del ejecutor de CI, aunque la instalación parezca rutinaria. ChainDrop utilizó un gancho de instalación malicioso de la misma manera.
El 2021 ua-parser-js El «compromise» es el ejemplo más habitual. Después de que la cuenta de npm del responsable del mantenimiento fuera pirateada, se distribuyeron tres versiones maliciosas junto con un preinstall un hook que instalaba un minero de criptomonedas en Linux y, en Windows, el minero junto con un malware dedicado al robo de credenciales. Se retiraron en unas cuatro horas, lo cual es rápido según los estándares de respuesta ante incidentes. El paquete registraba millones de descargas a la semana, por lo que los procesos de compilación automatizados lo obtenían sin que nadie tuviera que escribir su nombre.
{
"scripts": {
"preinstall": "node setup.js"
}
}Por fin se están resolviendo los impagos. pnpm No se han ejecutado scripts de compilación de dependencias sin autorización explícita desde la versión 10, y en las versiones actuales esas decisiones se registran en un allowBuilds mapa, y npm 12 bloques de scripts de instalación de dependencias que no están incluidos en allowScripts. Es importante saber cómo se comporta ese valor por defecto. El script se omite con una advertencia y la instalación se lleva a cabo con éxito, por lo que una dependencia nativa puede incluirse sin que su binario se haya compilado nunca. Una vez que apruebes el paquete, npm rebuild ejecuta las tareas de instalación que se han omitido, y en CI --strict-allow-scripts hace que un script sin revisar provoque un error de instalación, en lugar de que la instalación se quede a medias sin que nadie se dé cuenta.
Las versiones anteriores de npm no están desprotegidas. Simplemente tienen una configuración predeterminada diferente.
npm install --ignore-scriptsEsa solución es demasiado drástica. Provoca errores en paquetes que se compilan correctamente en el momento de la instalación, y no hace nada frente al código malicioso que espera a que tu aplicación lo importe. Considera una lista de permitidos explícita como la verdadera solución.
¿Por qué todo esto sigue funcionando?
Ninguno de estos ataques se resuelve con una sola persona o una sola herramienta. Se vuelven más difíciles cuando un equipo elimina la ambigüedad del proceso: paquetes privados con ámbito definido, enrutamiento determinista del registro, instalaciones fijas a partir de un archivo de bloqueo revisado, scripts de instalación permitidos por excepción en lugar de por defecto, y sugerencias de dependencias generadas por IA que se tratan como no verificadas hasta que alguien las compruebe.
Pero esperar que cada ingeniero detecte todos los paquetes maliciosos en cada instalación no es una política de seguridad. El paquete tiene que proceder de algún sitio, y ese sitio forma parte de tu perímetro de seguridad.
Para eso se ha creado SecureChain. En lugar de obtener los artefactos directamente de un registro público, se configura el gestor de paquetes para que apunte a una fuente seleccionada, en la que los paquetes se recompilan a partir de código fuente verificado en entornos aislados, se analizan en busca de malware y se actualizan a medida que surgen nuevas vulnerabilidades (CVE), con compilaciones firmadas y trazabilidad para su auditoría. Es compatible con JavaScript, Python, Java, Go, Rust y PHP, y los desarrolladores pueden seguir utilizando el gestor de paquetes con el que están acostumbrados.
Cuando el problema se debe a un paquete sin mantenimiento y no a uno malicioso, el servicio Endless Lifecycle Support (ELS) adapta las correcciones de seguridad a las versiones que ya tienes instaladas, de modo que sigues recibiendo parches incluso después de que finalice el soporte del desarrollador original.
Mis reflexiones finales
La confianza es un pilar fundamental del desarrollo de software moderno, pero lo que se aprovecha es la confianza ciega. Los atacantes buscan formas de colarse a través de errores tipográficos, la inteligencia artificial, cuentas secuestradas o la suposición de que un paquete conocido sigue siendo el que creías que era. No podemos controlar todo lo que ocurre en la web abierta.
Una cosa que sí puedes controlar es lo que acaba en tu entorno. Comprende cómo funcionan estos ataques, protege tu proceso de compilación, gestiona los permisos del registro y de los scripts, e intercala una fuente verificada entre los registros públicos y el entorno de producción. El código que distribuyes debe ser el código que realmente pretendes ejecutar.
