Cómo respondimos a un ataque a la cadena de suministro de npm

Kevin van Zonneveld

Cofundador · Ámsterdam, Países Bajos · Mostrar bio

El 12 de mayo de 2026, revisamos nuestra exposición a la campaña en curso Mini Shai-Hulud contra la cadena de suministro, después de que informes públicos describieran paquetes comprometidos en los ecosistemas de npm y PyPI. Estos incluían paquetes de TanStack y intercom-client.

No encontramos indicios de que los sistemas de producción, los datos de clientes o los paquetes publicados de Transloadit se vieran afectados. Sin embargo, aprovechamos el incidente para reforzar la instalación de dependencias y las rutas de publicación de GitHub Actions en nuestros repositorios.

Qué ocurrió

En resumen, los atacantes ya no dependen únicamente de tokens robados de gestores de paquetes ni de nombres de paquetes que suplantan otros mediante errores tipográficos. En el incidente de TanStack, el análisis posterior al incidente⁠ de los responsables de mantenimiento describe una cadena que combinó un flujo de trabajo pull_request_target, el envenenamiento de la caché de GitHub Actions y el acceso a tokens de publicación de confianza u OIDC. Como resultado, se pudieron publicar paquetes maliciosos mediante la infraestructura oficial de publicación.

El rastreador de Mini Shai-Hulud⁠ de Socket también vincula la campaña con paquetes comprometidos, como intercom-client@7.0.4 en npm y lightning 2.6.2/2.6.3 en PyPI. Según los informes, las cargas maliciosas atacan entornos de desarrollo y CI en busca de credenciales, como tokens de GitHub, tokens de npm, claves de servicios en la nube, claves SSH y configuraciones de herramientas de IA.

Esto es importante porque los sistemas de CI suelen tener acceso cercano al código fuente, las credenciales de implementación, los permisos para publicar paquetes y la infraestructura en la nube. La instalación de una dependencia maliciosa en el lugar equivocado puede convertirse en mucho más que un problema de desarrollo local.

Impacto en Transloadit

No encontramos indicios de impacto en los servicios de Transloadit ni en los datos de clientes.

Nuestra revisión incluyó:

• Revisar los repositorios que usan intercom-client. Encontramos estas dependencias en el repositorio del sitio web, la API y otros repositorios internos. Sin embargo, todas estaban fijadas y se resolvían como intercom-client@5.0.0, no como las versiones maliciosas 7.0.4 o 7.0.5 reportadas.
• Buscar archivos e indicadores sospechosos conocidos de la campaña, incluidos router_init.js, router_runtime.js, execution.js, archivos sospechosos de flujo de trabajo shai-hulud y la referencia maliciosa de Git de TanStack reportada.
• Buscar en las máquinas de desarrollo utilizadas en esta revisión el mecanismo de persistencia reportado para supervisar tokens de GitHub.
• Revisar nuestros flujos de trabajo de GitHub Actions para detectar el patrón de riesgo específico destacado en el análisis posterior al incidente de TanStack: código no confiable de una solicitud de cambios que cruza hacia una caché o un flujo de trabajo de publicación de confianza.

Las versiones afectadas de los paquetes que revisamos no estaban presentes en los archivos de bloqueo ni en las copias instaladas que se examinaron. Tampoco encontramos los indicadores conocidos de persistencia o de cargas maliciosas en los árboles de trabajo revisados.

Qué cambiamos

Abrimos y actualizamos varias solicitudes de cambios para reforzar la seguridad de nuestros repositorios. Estos cambios son pequeños a propósito: reducen la exposición de la cadena de suministro sin modificar el comportamiento del producto.

Los principales cambios son:

• Límites de antigüedad para dependencias. En los repositorios de Yarn que aún no tenían uno, añadimos npmMinimalAgeGate: 2880, que impide instalar versiones de paquetes publicadas en las últimas 48 horas. Esto da tiempo al ecosistema para detectar y eliminar muchas versiones comprometidas antes de que puedan incorporarse a nuestros builds.
• Instalaciones inmutables. Modificamos las instalaciones de CI que lo permitían para usar un comportamiento inmutable o congelado de los archivos de bloqueo, de modo que la CI no resuelva de forma oportunista nuevas versiones de dependencias.
• Límites de caché para publicaciones. Eliminamos la restauración de cachés compartidas de dependencias en rutas de publicación o capaces de publicar cuando podían atravesar límites de confianza. En particular, actualizamos las rutas de publicación o subida a la CDN en monolib, locutus y uppy.
• Revisión de la CI en repositorios públicos. Revisamos los repositorios públicos para detectar pull_request_target y flujos de trabajo con acceso a secretos. Cuando los repositorios públicos necesitan secretos para la CI, nuestro patrón preferido es una aprobación protegida por entorno y vinculada al código específico que se está probando, en lugar de un flujo «seguro para probar» basado únicamente en una etiqueta.
• Historial de Git verificado y de solo anexado. Habilitamos reglas de GitHub para toda la organización que exigen commits verificados y bloquean los force-pushes en los repositorios de Transloadit. Una investigación posterior confirmó que las ramas no predeterminadas y las referencias obsoletas forman parte de la superficie de ataque: si un atacante puede reescribir una rama compartida con metadatos de autor falsificados, el historial malicioso puede parecer más familiar de lo que realmente es.

Por qué esto ayuda

Ninguna configuración por sí sola evita todos los ataques a la cadena de suministro. El objetivo es establecer varias capas de obstáculos:

• Un límite de antigüedad para paquetes reduce la probabilidad de que instalemos una versión recién comprometida durante las primeras horas de un ataque.
• Las instalaciones inmutables hacen que la CI y las implementaciones reproduzcan el archivo de bloqueo revisado, en lugar de descubrir nuevas versiones durante la ejecución.
• Evitar las cachés compartidas en las rutas de publicación reduce la probabilidad de que tareas no confiables o de menor confianza dejen artefactos que una tarea posterior de publicación de confianza vaya a restaurar.
• Los permisos explícitos de GitHub Actions y las aprobaciones de entorno evitan que las tareas con acceso a secretos se ejecuten con código no revisado proveniente de forks.
• Los commits verificados dificultan la suplantación de identidad, y bloquear las actualizaciones que no sean de avance rápido conserva el historial revisable de las ramas compartidas.

El incidente de TanStack fue un recordatorio útil de que las cachés de builds y las tareas de publicación forman parte del perímetro de seguridad. Ahora somos más coherentes al tratarlos como tales.

Qué deben hacer los clientes

Esta revisión no requiere ninguna acción específica de los clientes de Transloadit.

Si instalaste algún paquete incluido públicamente entre los afectados por Mini Shai-Hulud el 29 de abril de 2026 o después, te recomendamos seguir las indicaciones de los responsables de mantenimiento del paquete correspondiente. En general, esto implica revisar los archivos de bloqueo y los registros de CI, eliminar las versiones afectadas y rotar cualquier credencial a la que se pudiera acceder desde los entornos donde quizá se ejecutaron los paquetes maliciosos.

Para tus propios sistemas de CI, recomendamos los mismos controles que estamos aplicando:

• Usa instalaciones basadas únicamente en archivos de bloqueo en los flujos de trabajo de CI e implementación.
• Añade límites de antigüedad de publicación para las dependencias cuando tu gestor de paquetes los admita.
• Evita las cachés de dependencias en los flujos de trabajo de publicación o implementación.
• Ten mucho cuidado con pull_request_target; no lo combines con la obtención de código no confiable de solicitudes de cambios ni con el acceso a secretos o tokens de escritura.
• Mantén los permisos de GitHub Actions tan limitados como sea posible y elévalos únicamente en la tarea que necesite el permiso.
• Deshabilita los force-pushes en las ramas compartidas del repositorio siempre que sea posible. Si los desarrolladores necesitan modificar el historial, es preferible crear ramas nuevas en lugar de reescribir ramas que otras personas o procesos automatizados podrían obtener.

Cierre

Agradecemos a los responsables de mantenimiento y a los investigadores que actuaron con rapidez para publicar detalles técnicos e indicadores. Esto permitió que equipos como el nuestro comprobaran rápidamente su exposición y convirtieran lo aprendido en medidas concretas de refuerzo de la seguridad.

Seguiremos supervisando la campaña y actualizaremos esta publicación si detectamos algún impacto importante en Transloadit o alguna acción que deban realizar los clientes.