Typosquatting: la amenaza silenciosa que acecha en tu instalación de npm

Ir directamente al resumen generado por IA de esta entrada del blog

Has escrito npm install mil veces. Probablemente también hayas escrito mal el nombre de un paquete al menos una vez y hayas tenido suerte. No todo el mundo la tiene. Los atacantes cuentan con ese único descuido —la confianza en la memoria muscular, la rápida pulsación de Intro— y el mismo ecosistema de paquetes que hace que el desarrollo en JavaScript sea tan rápido es lo que hace que el typosquatting sea tan eficaz.

En esta entrada se explica qué es el «typosquatting», cómo detectarlo y qué medidas concretas puedes tomar para proteger tus proyectos.

¿Qué es el «typosquatting»?

El «typosquatting» es la práctica de publicar un paquete malicioso con un nombre que se parezca mucho a uno popular y legítimo, con la esperanza de que los desarrolladores escriban mal el nombre, lo lean mal, lo copien de una fuente no fiable o no lo comprueben dos veces antes de instalarlo.

Algunos patrones habituales son:

Errores en los caracteres, omisiones o errores ortográficos: lodash se convierte en lodahs o loadsh
Trucos con el guion: babel-core vs babelcore
Pluralización: colores frente a color
Trucos sobre el ámbito y el espacio de nombres: @types/react (un paquete con ámbito real) frente a un falso, sin ámbito types-react
Homógrafos: sustitución de una letra minúscula l por una mayúscula I, o utilizar otros caracteres que se parecen

Una vez instalados, estos paquetes pueden hacer todo lo que hace un paquete npm auténtico: leer variables de entorno, extraer archivos .env o claves SSH, instalar puertas traseras o inyectar discretamente código malicioso en el resultado de tu compilación. Dado que los scripts del ciclo de vida de npm pueden ejecutarse durante la instalación, el daño puede producirse incluso antes de que hayas echado un vistazo al código.

El «typosquatting» no se limita a los paquetes. También aparece en las URL. Tomemos, por ejemplo, guthub.com. Si alguna vez has querido escribir «github.com» y has acabado en «guthub.com», has tenido suerte: ese dominio redirige al sitio web auténtico. Pero esa redirección es una cortesía que alguien ha configurado, no una garantía. Quien registre un error ortográfico habitual controla a dónde apunta, y si está en manos de alguien malintencionado, un simple error al teclear puede llevarte a un sitio clonado diseñado para robar tus credenciales. En el ecosistema de los paquetes, el peligro es aún más directo, ya que ese mismo tipo de error puede introducir código ejecutable directamente en tu proyecto.

¿Por qué precisamente JavaScript?

Esto no es exclusivo de JavaScript, pero el ecosistema de npm es un objetivo especialmente atractivo. El registro es enorme, muchos paquetes son mantenidos por equipos pequeños o por particulares, y los árboles de dependencias modernos pueden llegar a tener cientos o miles de paquetes debido a las dependencias transitivas anidadas. Si a esto le sumamos las escasas barreras para publicar y el carácter informal de la instalación de dependencias —en la que basta con echar un vistazo rápido—, el «typosquatting» tiene mucho margen para prosperar.

Ese mismo riesgo te acompaña en todos los gestores de paquetes. Solo cambia el comando:

yarn add nombre_del_paquete
pnpm add nombre_del_paquete
bun add nombre_del_paquete

Tanto si utilizas hilo, pnpmo bun, la sintaxis difiere de la de npm: los tres utilizan add en lugar de install. Sin embargo, todos ellos se alimentan de la misma fuente —el registro de npm—, por lo que, aunque el comando cambie, el problema de confianza sigue siendo el mismo. Un paquete mal escrito o introducido de forma maliciosa puede llegar a tu proyecto independientemente del gestor que utilices, incluso si nunca escribes tú mismo «npm install».

npm tampoco revoca el acceso de publicación de un mantenedor solo porque una cuenta deje de estar activa, y el ataque a Mastra de junio de 2026 demostró lo que eso permite. Los atacantes se hicieron con el control de la cuenta de un antiguo colaborador de Mastra cuyo acceso al ámbito @mastra nunca se había revocado y, a continuación, inyectaron easy-day-js —que a su vez es un typosquat de la popular biblioteca dayjs— en más de 140 paquetes de Mastra. Un ámbito de confianza se convirtió en una vía de distribución de una dependencia maliciosa que se hacía pasar por otra legítima.

Cómo identificar un paquete afectado por un «typosquatting»

Las señales de alerta no siempre son evidentes, pero unas cuantas comprobaciones pueden ayudarte a detectar un paquete sospechoso antes de que entre en tu proyecto:

Fíjate en el número de descargas y el historial de publicaciones. Un paquete que se presenta como una biblioteca «popular», pero que solo cuenta con unos pocos cientos de descargas y cuya fecha de publicación es de la semana pasada, es una señal de alarma. Compáralo con las estadísticas reales del paquete en npmjs.com.

Comprueba quién es el responsable del mantenimiento. ¿Coincide la cuenta de publicación con los responsables conocidos del proyecto real? Una cuenta nueva, un responsable desconocido o un paquete sin un historial de publicaciones significativo merecen una segunda mirada.

Lee atentamente el archivo package.json. Fíjate en la URL del repositorio, la licencia y la descripción. Los «typosquats» suelen copiar estos campos directamente del paquete legítimo, pero a veces el enlace al repositorio apunta a algún sitio inesperado o ni siquiera aparece.

Revisa los scripts de instalación antes de que se ejecuten. Revisa los scripts de instalación antes de que se ejecuten. preinstall, install, y postinstall de package.json merecen un análisis especial, ya que pueden ejecutar código durante la instalación. Si una simple biblioteca de utilidades incluye un script de postinstalación ofuscado que se conecta a una URL remota, considéralo una señal de alerta grave: así es exactamente como funcionó la dependencia easy-day-js en el ataque a Mastra, descargando y ejecutando una carga útil de segunda fase.

Utiliza el buscador oficial del registro, no te lo inventes. Busca en npmjs.com, copia el comando de instalación de la documentación oficial del proyecto o utiliza la función de autocompletado de tu IDE, en lugar de escribir de memoria nombres de paquetes que no conoces. La memoria muscular es útil hasta que instalas el paquete equivocado.

Presta atención a los cambios de última hora en las dependencias. Si un package-lock.json o yarn.lock , o pnpm-lock.yaml Si el diff muestra un cambio en el nombre de una dependencia que no esperabas, detente e investiga antes de fusionar. Lo mismo se aplica a cualquier paquete recién añadido que nadie del equipo haya introducido intencionadamente.

Medidas prácticas de protección para tu proyecto

La revisión manual es útil, pero por sí sola no es escalable. El enfoque más eficaz consiste en incorporar medidas de protección estructurales en el proceso que sigue tu equipo para instalar, revisar y promover las dependencias:

Fija tus dependencias. Guarda tu package-lock.json o yarn.lock y utiliza npm ci en los procesos de CI/CD en lugar de npm install. Esto garantiza que las compilaciones utilicen exactamente las versiones que has verificado, y no las que se resuelvan en el momento de la instalación.

Utiliza herramientas de análisis automatizadas. npm audit, Snyk, Socket y GitHub Dependabot —conocidas en conjunto como herramientas de análisis de la composición del software (SCA)— pueden detectar vulnerabilidades conocidas, paquetes maliciosos y scripts de instalación inesperados. Socket, en particular, está diseñado específicamente para detectar riesgos en la cadena de suministro, como el typosquatting y los hooks de postinstalación maliciosos. Ninguna de estas herramientas lo detecta todo, pero juntas ofrecen a tu equipo muchas más posibilidades de detectar los riesgos antes de que lleguen a producción.

Fija versiones concretas para las dependencias críticas. Evita rangos de semver demasiado amplios (^ o ~) para los paquetes que intervienen en operaciones sensibles, de modo que una actualización automática no pueda introducir silenciosamente una versión comprometida. La fijación también mantiene la coherencia en el comportamiento de los paquetes entre equipos, entornos y procesos de CI/CD.

Desactiva los scripts de forma predeterminada cuando sea conveniente.

Desactiva los scripts de forma predeterminada cuando sea conveniente. Al ejecutar instalaciones con –ignore-scripts en la integración continua (CI) y, a continuación, incluir explícitamente en la lista de permitidos los paquetes que realmente necesitan pasos de compilación, reduce el alcance de un gancho de postinstalación malicioso. También merece la pena tener en cuenta pnpm en este sentido: desde la versión 10, bloquea por defecto los scripts del ciclo de vida de las dependencias y requiere que los apruebes a través de una lista de permitidos.

Ejecutar npm install –ignore-scripts en la integración continua (CI) y, a continuación, incluir explícitamente en la lista de permitidos los paquetes que realmente necesitan scripts de instalación, reduce el alcance de un gancho postinstall malicioso. Este es un caso de uso ideal para pnpm. Pnpm ignora los scripts de instalación de forma predeterminada desde la versión 10. Puedes utilizar la opción –ignore-scripts en la línea de comandos o en el archivo .npmrc y a nivel global.

Adopta un registro privado o un proxy. Herramientas como Verdaccio, Sonatype Nexus, JFrog Artifactory o las propias funciones de registro privado de npm permiten a los equipos duplicar, aprobar y controlar los paquetes antes de que estén disponibles para los desarrolladores. Esto te proporciona un punto de control en el que se pueden bloquear los paquetes sospechosos que se parezcan a otros legítimos antes de que lleguen al ordenador de un desarrollador.

Revisa las nuevas dependencias como parte de la revisión del código. Trata la incorporación de un nuevo paquete como si se tratara de incorporar a un nuevo colaborador con acceso a tu código fuente, ya que, en la práctica, es algo muy similar. Crea una política de seguridad que defina cómo se aprueban los nuevos paquetes, qué deben comprobar los revisores y desde qué fuentes está autorizado tu equipo a realizar instalaciones. Herramientas como SecureChain pueden facilitar esta tarea al proporcionar a los equipos una fuente seleccionada de paquetes de código abierto previamente verificados.

Forma a tu equipo. Una conversación de cinco minutos sobre los patrones de «typosquatting» puede evitar un incidente costoso. Incorpórala a la formación inicial de cualquier puesto que tenga que ver con package.json. Crea una política de equipo, asegúrate de incluir los controles de seguridad como prioridad máxima y velad por su cumplimiento.

Una breve lista de comprobación mental

Antes de añadir CUALQUIER nueva dependencia, pregúntate:

¿Es este el nombre que realmente quería escribir?
¿Te parecen fiables las cifras de descargas y el historial de publicaciones?
¿El repositorio de código fuente corresponde a algún proyecto que reconozca o que pueda verificar?
¿Existen scripts de instalación? ¿Entiendo qué hacen, por qué existen y si son necesarios?
¿Ha detectado algo mi herramienta de análisis?

Reflexiones finales

El «typosquatting» es eficaz porque se aprovecha de la confianza y la rutina, dos aspectos en los que los desarrolladores confían constantemente. La buena noticia es que para reducir el riesgo no es necesario replantearse por completo todo el flujo de trabajo.

Pasar de la memoria muscular a nombres de paquetes verificados, árboles de dependencias fijos, análisis automatizados, registros aprobados y un momento de escepticismo sano antes de cada nueva instalación eliminará la gran mayoría de esta superficie de ataque.

Resumen