Zapocalypse: cuando cinco fallos 'inocentes' se combinan en un ataque devastador

En mayo de 2026, los investigadores de Token Security revelaron una cadena de explotación de cinco etapas a la que bautizaron como "Zapocalypse". Este hallazgo demostró cómo una serie de anti-patrones ya conocidos podían combinarse para convertir una simple cuenta gratuita de Zapier en acceso de escritura sobre los paquetes públicos del SDK para desarrolladores e, incluso, sobre paquetes internos de la compañía. Lo más llamativo es que cada eslabón individual era un problema de seguridad comprendido, que un solo equipo podría haber descartado como aceptable. La vulnerabilidad no residía en un único sistema, sino en la composición entre cinco equipos diferentes que nunca tuvieron que trazar una ruta de ataque de forma conjunta .

Etapa 1: Escape del Sandbox mediante "buceo" en la memoria

La cadena comenzó dentro de la funcionalidad Code by Zapier, que ejecuta código Python y JavaScript proporcionado por el usuario dentro de contenedores de AWS Lambda. El manejador de Lambda de Zapier intentaba limpiar las credenciales de AWS de las variables de entorno eliminándolas de os.environ con la instrucción de Python

del os.environ[k]

Los investigadores explotaron esta debilidad leyendo /proc/self/mem y aplicando cuatro patrones de expresiones regulares (regex) contra las regiones de memoria legibles. Así lograron recuperar tokens de sesión AWS STS activos para el rol IAM de la Lambda, evadiendo el sandbox por completo .

Etapa 2: Enumeración de repositorios ECR con permisos mínimos

El rol de AWS recuperado tenía el engañoso nombre de allow_nothing_role (algo así como "rol_que_no_permite_nada"), pero concedía cuatro permisos de Elastic Container Registry (ECR): ecr:DescribeRepositories, ecr:ListImages, ecr:BatchGetImage y ecr:GetDownloadUrlForLayer .

Estos cuatro permisos resultaron ser suficientes para extraer imágenes de contenedores directamente a través de la API de AWS, sin necesidad de un token de autenticación para el registro Docker. Usándolos, los investigadores enumeraron 1,111 repositorios de producción y extrajeron imágenes de contenedores mediante las APIs de obtención de capas .

Etapa 3: Recuperación de un token NPM desde el historial de la imagen

Dentro de una de las imágenes de contenedor extraídas, los investigadores descubrieron un token de publicación de NPM que se había filtrado en el historial de configuración del contenedor. El token se había pasado al proceso de construcción a través de una instrucción ARG en el Dockerfile, la cual se serializa de forma permanente en el campo inmutable history[] de la imagen. Esto significaba que cualquiera que pudiera extraer la imagen podía recuperar el token .

Etapa 4: Acceso de publicación a NPM sin segundo factor de autenticación

El token NPM recuperado contenía tres propiedades críticas:

action: write

name: null

bypass_2fa: true

La configuración

bypass_2fa: true

Etapa 5: Un punto de apoyo en la cadena de suministro y ejecución de código en el navegador

El paquete más crítico de toda la cadena era zapier-design-system, el cual se carga en cada sesión autenticada de zapier.com. Los investigadores verificaron esta ruta de carga a través de las herramientas de desarrollo del navegador y se detuvieron en este punto; no publicaron un paquete malicioso .

Si un atacante hubiera publicado una versión envenenada, esta habría ejecutado JavaScript controlado por el atacante dentro del origen autenticado de zapier.com en la siguiente versión. Desde esa posición, un atacante podría crear Zaps, Tablas y servidores MCP, además de operar integraciones existentes a través de la plataforma en nombre de los usuarios autenticados. Aunque los tokens OAuth y las claves API de los servicios conectados permanecen del lado del servidor y no habrían quedado expuestos directamente al navegador, el impacto operacional habría sido igualmente grave .

La respuesta de Zapier

Token Security presentó el informe el 12 de febrero de 2026. En solo cuatro días, Zapier había evaluado el reporte, revocado el token NPM filtrado y reforzado el rol de AWS subyacente. La corrección se confirmó como completa el 5 de marzo de 2026. Zapier informó que no había evidencia de explotación activa .

Los investigadores recibieron la recompensa máxima del programa, de 3,000 dólares, y Zapier se comprometió a revisar el límite de la recompensa en su próxima revisión del programa .

Vale la pena aclarar que esta divulgación de investigación es independiente del ataque real a la cadena de suministro que sufrió la cuenta NPM de Zapier el 24 de noviembre de 2025, cuando el gusano Shai Hulud 2.0 comprometió la cuenta e infectó 425 paquetes .

La gran lección: las vulnerabilidades compuestas caen entre los equipos

Yair Balilti, Líder del Equipo de Investigación de Seguridad en Token Security, expresó el hallazgo central de esta manera:

"Cada eslabón de la cadena era un patrón conocido. La vulnerabilidad era la composición, y la composición es exactamente lo que queda fuera del alcance de los equipos. El sandbox de Lambda, ECR e IAM, el token de CI de GitLab, la publicación en NPM, el navegador... cada uno pertenece a un grupo diferente, y cada grupo puede mirar su propia parte y concluir, razonablemente, que está bien. El riesgo solo aparece cuando trazas una ruta a través de todos ellos."

La conclusión es que ningún equipo individual era responsable de una vulnerabilidad concreta. El equipo del sandbox de Lambda no veía problema con la filtración de memoria, porque se suponía que el token estaba fuera de alcance. El equipo de IAM veía un rol limitado a acciones de solo lectura en ECR. El equipo de CI/compilación pasó el token NPM como un ARG de compilación. El equipo de NPM gestionaba un token con acceso de escritura. El equipo del navegador cargaba un paquete de sistema de diseño. Cada decisión era individualmente razonable, pero la cadena a través de los cinco sistemas resultó catastrófica .

Esto demuestra que las revisiones de identidad y acceso deben trazar las rutas de ataque a través de las fronteras del sistema, en lugar de auditar los permisos de cada componente de forma aislada. Las organizaciones necesitan revisiones de seguridad entre equipos que examinen cómo configuraciones aparentemente inofensivas se componen en cadenas de ataque peligrosas cuando los sistemas interactúan .