Zapocalypse: cuando cinco fallos 'inocentes' se combinan en un ataque devastador
Investigadores de Token Security encadenaron cinco anti patrones para escalar desde una cuenta gratuita de Zapier hasta el acceso de escritura en sus paquetes NPM públicos e internos, un ataque que partió de un escape... Zapier gestionó el reporte en cuatro días, revocó el token filtrado y confirmó la corrección tot...
What was the "Zapocalypse" exploit chain in Zapier, how did each of its five stages work from sandbox escape to NPM publish access, what vulThe Zapocalypse chain connected AWS Lambda, ECR, container image history, NPM tokens, and browser code execution—none of which were individually vulnerable.
Prompt de IA
Create a landscape editorial hero image for this Studio Global article: What was the "Zapocalypse" exploit chain in Zapier, how did each of its five stages work from sandbox escape to NPM publish access, what vul. Article summary: Here is a comprehensive breakdown of the "Zapocalypse" exploit chain, based on the disclosure by Token Security researchers and the reporting by Help Net Security [5].. Topic tags: general, documentation, general web. Reference image context from search candidates: Reference image 1: visual subject "# Welcome to IT-Branschen – The Channel for IT News, Cybersecurity and Digital Trends. ## For Companies, Suppliers and Decision Makers in the IT Industry. ### Digital strategy and" source context "Zapier's NPM account hacked, 425 packages infected" Reference image 2: visual subject "A newly disclosed exploit chain dubbed Zapocalypse shows how a low-privilege code-ex
openai.com
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]
, justo antes de pasar el código a exec(). Sin embargo, este enfoque solo llama a unsetenv de libc: no borra los bytes que permanecen en la memoria del proceso (el heap) .
Studio Global AI
Search, cite, and publish your own answer
Use this topic as a starting point for a fresh source-backed answer, then compare citations before you share it.
¿Cuál es la respuesta corta a "Zapocalypse: cuando cinco fallos 'inocentes' se combinan en un ataque devastador"?
Investigadores de Token Security encadenaron cinco anti patrones para escalar desde una cuenta gratuita de Zapier hasta el acceso de escritura en sus paquetes NPM públicos e internos, un ataque que partió de un escape...
¿Cuáles son los puntos clave a validar primero?
Investigadores de Token Security encadenaron cinco anti patrones para escalar desde una cuenta gratuita de Zapier hasta el acceso de escritura en sus paquetes NPM públicos e internos, un ataque que partió de un escape... Zapier gestionó el reporte en cuatro días, revocó el token filtrado y confirmó la corrección total para el 5 de marzo de 2026, sin encontrar evidencia de explotación real [5].
¿Qué debo hacer a continuación en la práctica?
La lección central es que ningún equipo era dueño de una vulnerabilidad individual: los equipos de Lambda, IAM, CI, NPM y navegador tomaron decisiones razonables por separado, pero que resultaron catastróficas al comb...
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
y
bypass_2fa: true
. Esta combinación otorgaba derechos de publicación sobre todos los paquetes que la cuenta de NPM asociada pudiera publicar, incluyendo zapier-platform-core, zapier-platform-cli y zapier-design-system.
La configuración
bypass_2fa: true
significaba que no se requería autenticación de dos factores para ninguna acción de publicación, lo que en la práctica concedía acceso de escritura sin restricciones al registro de NPM para todos los paquetes asociados .
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 .
socdefenders.aiZapier exploit chain shows how known anti-patterns ...
Comments
0 comments