Deconstructing “Zapocalypse”: A Sophisticated Multi-Stage Attack Chain

The security research community was recently alerted to a critical vulnerability chain dubbed “Zapocalypse.” This discovery demonstrates how a seemingly isolated, sandboxed environment—specifically Zapier’s “Code by Zapier” feature—could serve as the initial entry point for a full-scale account takeover across the entire platform.

The findings, documented by Token Security, are particularly striking because the exploit did not require “zero-day” vulnerabilities. Instead, it leveraged a sophisticated orchestration of five common architectural weaknesses: overly permissive cloud IAM roles, improper credential sanitization in memory, secret exposure within container metadata, and excessive write permissions on internal NPM packages.

Ultimately, this chain allowed for the injection of malicious JavaScript into the browsers of every authenticated Zapier user. While this method does not expose the raw OAuth tokens stored on the server, it enables an attacker to perform any action a user can, effectively bypassing all frontend security controls.

Phase 1: Breaking the Sandbox via Memory Residuals

The attack vector begins within the “Code by Zapier” execution environment, where users can run custom Python or JavaScript logic. The researchers initiated a reconnaissance phase by executing a simple os.system('env') command within a Python block to map the environment. They identified the runtime as AWS Lambda (Python 3.11) operating within the us-east-1 region.

Upon inspecting the lambda_function.py deployment logic, they observed a security measure intended to scrub sensitive AWS environment variables (such as AWS_ACCESS_KEY_ID and AWS_SESSION_TOKEN) before the user’s code was executed. The developers relied on an IAM role named allow_nothing_role, assuming that even if keys were present, the role itself lacked permissions.

This defense-in-depth strategy failed due to two fundamental errors:

1. Incomplete Sanitization: Removing a variable from os.environ deletes the reference in the environment dictionary, but it does not overwrite or “zero out” the actual bytes in the process’s heap memory.
2. Misconfigured IAM: The allow_nothing_role was not, in fact, restricted to “nothing.”

To exploit the memory residual, the researchers implemented a custom memory-scanning script. By reading from /proc/self/mem and using /proc/self/maps to navigate the process’s memory layout, they applied regular expressions to hunt for specific patterns, such as the IQoJ prefix characteristic of AWS STS session tokens. Despite the variables being “deleted,” the script successfully recovered valid, live AWS credentials.

Phase 2: Lateral Movement via ECR Enumeration

With valid STS credentials in hand, the researchers moved from code execution to lateral movement. Using standard IAM enumeration techniques, they discovered that the compromised role possessed sufficient permissions to interact with Amazon Elastic Container Registry (ECR) APIs.

Specifically, the role could invoke DescribeRepositories, ListImages, BatchGetImage, and GetDownloadUrlForLayer. This allowed the researchers to bypass the standard ecr:GetAuthorizationToken flow and programmatically pull over 1,000 private container images directly from S3, effectively turning a single Lambda execution into a massive data exfiltration operation.

Phase 3: Secret Leakage and Frontend Hijacking

The final stage of the attack involved deep inspection of the downloaded container images. While filesystem searches yielded little, the researchers looked into the image metadata. By analyzing the configuration JSON and the build history of the images, they identified an NPM publish token that had been inadvertently baked into the container via ARG or ENV instructions during the build process.

This leaked token was highly privileged: it bypassed multi-factor authentication (MFA) and possessed broad write access across the organization’s NPM scope. This included access to the @zapier/* internal namespace and, most critically, the zapier-design-system package.

The zapier-design-system is a core dependency loaded into every authenticated session on zapier.com. By publishing a compromised version of this package, an attacker could execute a Supply Chain Attack, injecting malicious JavaScript that would run automatically in the context of every logged-in user.

This level of access allows an attacker to manipulate the Document Object Model (DOM), drive the UI, and trigger API calls as the victim. While the attacker cannot “steal” the underlying OAuth tokens, they can perform any operation the user can—creating, deleting, or modifying Zaps, Tables, and automations—resulting in a total platform account takeover.