Zapocalypse Attack Lets Threat Actors Hijack Zapier Accounts

“Zapocalypse” is a newly disclosed attack chain that shows how attackers could have abused Zapier’s “Code by Zapier” feature to move from a single sandboxed Python step to a potential full-scale Zapier account takeover.

The research, carried out by Token Security, is notable because it did not rely on any unknown zero‑days or exotic primitives. Instead, it chained together five well‑understood weaknesses: overly powerful cloud roles, unsafe credential handling in memory, secret leakage through container images, and overly broad NPM publish rights to a frontend package loaded into every authenticated Zapier session.

The result was a realistic path to inject attacker‑controlled JavaScript into the browsers of all logged‑in Zapier users, allowing an attacker to act as those users across the platform, even though raw OAuth tokens for connected third‑party services would remain server-side.

Zapocalypse Attack Hijack Zapier Accounts

The chain began inside Zapier’s “Code by Zapier” step, where users can execute Python or JavaScript as part of their Zaps. The researchers started with a simple environment inspection using os.system(‘env’) in a Python code block.

They confirmed they were running in AWS Lambda with Python 3.11 in the us‑east‑1 region. They then examined the deployed lambda_function.py on disk.

They found logic that explicitly scrubbed AWS credentials, such as AWS_ACCESS_KEY_ID and AWS_SESSION_TOKEN , from environment variables before executing user code. A comment in the handler suggested that this was mainly to avoid false‑positive reports and that real protection came from an IAM role called allow_nothing_role.

However, this assumption failed in two ways. First, deleting keys from os.environ does not zero the underlying bytes in process memory. Hence, the credentials still existed in the heap. Second, the role did not actually “allow nothing”; it turned out to have useful read permissions.

To prove the first point, the researchers wrote a memory‑scanning Python script that ran inside the same Lambda process and read from /proc/self/mem, guided by /proc/self/maps, applying regular expressions to search for AWS access key formats and the IQoJ prefix used in STS session tokens.

Even though the environment variables were gone, the script recovered valid STS credentials. When they tested those credentials with aws sts get-caller-identity, they confirmed they belonged to the supposedly restricted allow_nothing_role in Zapier’s AWS account. With live AWS credentials in hand, the next step was lateral movement.

The team used standard IAM enumeration techniques and found that this role could call ECR APIs such as DescribeRepositories, ListImages, BatchGetImage, and GetDownloadUrlForLayer.

That combination enabled them to list more than 1,000 private ECR repositories and programmatically download container images directly from S3, without ever calling ecr:GetAuthorizationToken or using Docker’s usual authentication flow.

Once they had local copies of these images, the researchers started hunting for secrets. They first looked in filesystems, but the most critical secret emerged from image metadata.

By fetching each image’s config JSON and reviewing the build history, they discovered that an NPM publish token had been injected via ARG or ENV during the container build.

That token, when inspected, had write access, bypassed two‑factor authentication, and was not scoped to a single package. It effectively granted the ability to publish any package the associated NPM account could control, including internal @zapier/* packages and, crucially, a private zapier-design-system package used by the Zapier frontend.

Developer tools in the browser confirmed that this design‑system bundle was loaded on every authenticated zapier.com page. If an attacker used the leaked token to publish a tampered version of this package, they could insert JavaScript that runs automatically for every logged‑in user, for example by dynamically loading a remote script.

From that point, the attacker’s code would execute in the context of the authenticated Zapier origin. It could drive the UI and APIs as the user, creating and modifying Zaps, altering Tables and automations, and triggering actions through existing connections.

Although the attacker would not see raw OAuth tokens for connected services, the ability to operate as the user inside Zapier represents a full platform account takeover scenario with significant downstream impact.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.