Alarma de malware en Zod 4.6.6: el commit malicioso nunca llegó a npm

Zod 4.6.6, la versión más reciente de la popular biblioteca de validación para TypeScript, salió el 11 de octubre de 2026. Su página de versión enumera commits de un ataque de malware, y los desarrolladores dieron la alarma en GitHub y Hacker News. Esos commits se subieron el 21 de septiembre y se revirtieron el mismo día. Según el aviso de seguridad de GitHub, los cambios maliciosos en Zod nunca llegaron a npm, el registro donde se publican los paquetes de JavaScript.

Zod comprueba que los datos, como un formulario o la respuesta de una API, tienen la forma que espera un programa. Muchos proyectos de TypeScript dependen de él.

Por qué Zod 4.6.6 parecía infectado

La página de la versión 4.6.6 enumera todos los commits desde la versión anterior, la 4.6.5. Esa lista incluye dos commits titulados «Fix bugs and improve performance» y cambios de versión llamados «4.6.7» y «4.6.8». También incluye dos cambios en la configuración de publicación: «ci: publish to npm with NPM_TOKEN» y «ci: drop the npm environment approval gate from publish».

Una incidencia de GitHub titulada «Suspicious preinstall script in v4.6.6 commit history» señaló el primero de esos commits. Un hilo de Hacker News preguntaba «Zod 4.6.6 compromised by malware?». El autor de la incidencia añadió una advertencia:

El cambio parece haberse revertido antes de la versión final, y los archivos sospechosos no parecen estar presentes en la versión 4.6.6 publicada en npm.

La misma lista también incluye «Cleanup bad commits (#6620)», el cambio que los eliminó.

Qué hizo el ataque del 21 de septiembre

El aviso de GitHub da la cronología. El mismo cargador llegó a tres proyectos en menos de una hora.

Hora (UTC)	Repositorio	Qué ocurrió
11:56	colinhacks/zod	Commit d821685, «Fix bugs and improve performance»
12:37	standard-schema/standard-schema	Commit con el mismo título y el mismo cargador
12:54	nubjs/nub	Commit con el mismo título y el mismo cargador
13:00	nubjs/nub	Seguimiento, «chore: update npm/nub package»
13:09	npm	Análisis de @nubjs/nub@0.9.4 registrado; la versión se bloqueó

El commit de Zod añadió dos archivos de cuatro líneas llamados meta.test.mjs, uno en el paquete principal y otro en Zod Mini. A pesar del nombre, no son pruebas. El commit también añadió una entrada preinstall para ejecutarlos. Eso es un hook de instalación: código que se ejecuta cuando se instala un paquete. Subió la versión a 4.6.6 y cambió el flujo de publicación para que un push a la rama principal iniciara una publicación.

El cargador pide una dirección web a un contrato inteligente, un pequeño programa almacenado en la cadena de bloques de Ethereum. Después descarga JavaScript desde esa dirección, lo ejecuta con los permisos del usuario que instala y borra sus archivos temporales. Como la dirección viene de la cadena de bloques, el código del repositorio nunca muestra dónde está la carga útil. El malware de npm MALFEX, del que se informó este mes, usa un truco parecido con Solana.

Por qué nada llegó a npm

El mantenedor, colinhacks en GitHub, escribió en el hilo del aviso: «Parece que se comprometió algún tipo de credencial de git push, no un token de npm ni de GitHub». El mantenedor también escribió: «El ataque consistió en commits maliciosos y pushes etiquetados a main».

Otros commits de ese día intentaron forzar una publicación. Eliminaron el paso de aprobación, añadieron una vía de publicación que usaba un secreto NPM_TOKEN y subieron la versión dos veces. Según el mantenedor, el flujo de publicación de Zod no estaba expuesto a este tipo de ataque desde que npm eliminó la publicación basada en tokens el pasado diciembre. El aviso afirma que los cambios en Zod y standard-schema «no llegaron a la publicación en npm».

Nub fue distinto. Su publicación podía iniciarse creando una etiqueta, así que @nubjs/nub@0.9.4 llegó al proceso de publicación de npm. El registro retuvo la versión para revisarla, encontró el código malicioso y la bloqueó antes de que nadie pudiera instalarla.

La pull request #6620, «Cleanup bad commits», revirtió seis commits y se fusionó el 21 de septiembre. Eliminó el nuevo flujo de publicación del atacante y los archivos del cargador, quitó las entradas preinstall y devolvió la versión a la 4.6.5.

Cómo se publicó Zod 4.6.6

Según su entrada en el registro de npm, la 4.6.6 la publicó GitHub Actions mediante publicación de confianza (trusted publishing), con la aprobación de colinhacks. La publicación de confianza permite que npm acepte una versión solo desde un flujo de trabajo de GitHub concreto, así que no hay ningún token de larga duración que robar. A principios de este mes, npm permitió que la publicación de confianza mueva dist-tags como latest. El paquete lleva una atestación de procedencia, un registro firmado de dónde se compiló. Su manifiesto no incluye ningún script preinstall, install ni postinstall.

La versión también refuerza el proceso. Dos de sus cambios, #6622 y #6638, dejan en espera las nuevas versiones de npm en lugar de publicarlas y detienen cada ejecución hasta que esas versiones se aprueban. El 24 de septiembre, el mantenedor escribió que todos sus paquetes de npm usan ahora publicación por etapas que solo puede iniciarse a mano.

Según el mantenedor, la forma en que se obtuvo la credencial de push sigue investigándose junto con GitHub.

Qué significa para los desarrolladores

• No hay señales de malware en el Zod 4.6.6 de npm. Su manifiesto no tiene hook de instalación y lleva procedencia. npm view zod@4.6.6 scripts muestra los scripts sin instalar nada.
• Busque el dominio de entrega en los registros. El aviso indica dsakldjklsaj33112[.]com como indicador. Revise las máquinas que compilaron Zod, standard-schema o nub desde el código fuente de Git el 21 de septiembre. Quite los corchetes al buscar.
• Desactive los scripts de instalación cuando pueda. Este ataque dependía de un hook preinstall. La opción ignore-scripts de npm impide que esos hooks se ejecuten. Compruebe que el proyecto sigue compilando, ya que algunos paquetes necesitan sus scripts.
• Los mantenedores pueden copiar la configuración de Zod. El atacante podía hacer push a main y editar el flujo de trabajo, pero aun así no pudo publicar Zod. La publicación de confianza y un paso de aprobación manual resistieron. Una publicación que empieza con una etiqueta, como la de nub, es el diseño más débil.