Zapocalypse Is a Reminder That Attack Chains Are Built in the Seams

Close-up of colorful source code on a computer screen, used as a visual metaphor for SaaS supply-chain risk.

Token Security’s Zapier research did not need a zero-day. It chained ordinary mistakes across Lambda, ECR, Docker builds, npm publishing, and browser-delivered JavaScript.

In Token Security’s writeup, “Zapocalypse: The Attack Chain That Could Have Hijacked Zapier,” the scary part is not a single brilliant exploit primitive. It is how normal-looking decisions across different systems combined into a credible platform-wide compromise path.

That is what makes it useful for red teamers.

The researchers started from a sandboxed Code by Zapier block on a free-tier account and ended with npm publishing rights to Zapier packages, including a private design-system package loaded into authenticated Zapier browser sessions. Zapier remediated the issue under coordinated disclosure: Token Security reported it on February 12, 2026, Zapier revoked the npm token and tightened the ECR role by February 16, and full remediation was confirmed on March 5. Zapier also said there was no evidence of exploitation in the wild and that customer-side action was not required.

Still, this is exactly the kind of chain worth studying. Not because every company has Zapier’s exact architecture, but because plenty of companies have the same ingredients: user-controlled code execution, cloud execution roles, container registries, CI tokens, npm packages, frontend bundles, and business-critical browser sessions.

The exploit chain in plain English

The chain began with Code by Zapier, a product feature that lets users run Python or JavaScript as part of an automation. That means the researchers were not smuggling code into a system that never expected it. They were using a feature whose whole purpose is to run customer-provided code.

Inside the Python runtime, basic probing showed the code was running in AWS Lambda on Python 3.11 in us-east-1. The obvious AWS credential environment variables were not present. That looked good at first glance. Zapier’s handler scrubbed credentials from the environment before passing user code into exec().

The problem was the way the scrubbing worked.

According to Token Security, the handler used del os.environ[k]. In Python, that removes the key from the environment mapping and calls unsetenv() underneath. What it does not do is overwrite the memory that previously held the value. The bytes can still be present in the process address space. The researchers read accessible process memory through /proc/self/mem and recovered live AWS STS session credentials with regex patterns.

That is the first lesson: removing a secret from the easy interface is not the same as destroying the secret. If untrusted code runs in the same process that once held credentials, assume memory artifacts are part of the attack surface.

The recovered role had an encouraging name: allow_nothing_role. The name did not match reality. Enumeration showed permissions including ecr:DescribeRepositories, ecr:ListImages, ecr:BatchGetImage, and ecr:GetDownloadUrlForLayer. Those permissions were enough to enumerate Zapier's private ECR repositories and pull image contents through the ECR API flow, even without the usual Docker login path.

Token Security reported seeing 1,111 production repositories. That number should make any cloud team uncomfortable. A role intended to allow nothing had enough read access to turn a sandbox escape into large-scale container registry inspection.

The next link was the container build process. The researchers found an npm publish token exposed in image configuration history. The token had apparently been passed through a Docker build mechanism where secrets can end up serialized into metadata. Token Security's writeup calls out the core issue clearly: ARG is not a secret.

When they introspected the npm token, its metadata showed write capability, no package-specific scope, and 2FA bypass. In CI contexts, 2FA bypass is common because an automated pipeline cannot complete an interactive MFA challenge. But in this chain, that meant the stolen token could publish packages the account was allowed to publish without another gate.

That included public Zapier developer SDK packages and a private package called zapier-design-system, which Token Security says was bundled into Zapier's authenticated web application.

At that point the researchers stopped short of exploitation. They did not publish a malicious package. They demonstrated publish capability, confirmed the frontend package loaded in authenticated Zapier sessions, and described the impact: a malicious package version could have delivered attacker-controlled JavaScript inside the zapier.com authenticated origin.

That distinction matters. This was not a claim that raw OAuth tokens or API keys for connected apps would spill into the browser. Zapier stores those server-side. But browser-origin control is still serious. If attacker JavaScript can run as the logged-in user, it may be able to drive whatever the legitimate UI and APIs allow that user to do: create Zaps, modify automations, create Tables, create MCP servers, and trigger connected workflows through Zapier’s own backend.

Why this should interest red teams

A moderate, useful takeaway is that this chain is less about “Zapier had one bug” and more about “composition creates new privilege.”

Each team could have looked at its own layer and felt mostly fine. The Lambda team removed credentials from the visible environment. The IAM role did not have broad admin privileges. The ECR access did not include ecr:GetAuthorizationToken. The npm token existed for CI automation. The frontend design-system package was a normal dependency.

The risk appeared when someone walked the path end to end.

That is a red-team lesson. Modern SaaS attack paths often do not look like one giant vulnerability. They look like five small assumptions connected by automation. One weak sandbox boundary leads to leftover credentials. Leftover credentials lead to registry read access. Registry read access leads to build metadata. Build metadata leads to a CI token. The CI token leads to software supply-chain control. Supply-chain control leads to authenticated browser execution.

If your assessments stop at "the role cannot call admin APIs" or "the token is only used in CI," you can miss the actual blast radius.

This also raises a practical scoping point. Red teams and internal security teams should ask for permission to test across the seams, not just inside one box. A narrow Lambda sandbox review might find the memory issue but miss ECR. A cloud IAM review might flag ECR read access but miss npm publish rights. A CI/CD review might find the npm token but miss the browser-origin impact. The interesting story is the connective tissue.

How to test your own setup safely

You do not need to reproduce Token Security’s exploit to learn from it. In most environments, you should not try to dump live process memory or pull production images from a role unless that is explicitly in scope. But you can run safe checks that validate whether your architecture has the same failure modes.

Start with user-controlled code execution. If customers, employees, plugins, workflows, notebooks, or automations can run code, map exactly what process starts with credentials and what process runs untrusted code. If credentials are injected and then “removed,” treat that as suspect. Prefer isolation where the untrusted code never shares a process with sensitive material in the first place.

Next, review execution roles by effective permission, not by name. Names like allow_nothing_role, sandbox_role, or restricted_runner are comforting but irrelevant. Use IAM Access Analyzer, policy simulation, or read-only enumeration in a test account to confirm what the role can actually do. Pay special attention to registry, artifact, secrets, logs, and metadata access. Read permissions can become powerful when artifacts contain secrets.

For ECR and other registries, test whether a workload role can list repositories, fetch manifests, or download layers. Many teams think of registry pulls as requiring Docker login, but registry APIs often expose equivalent paths through separate permissions. If a role can read image layers or config blobs, assume it can inspect build history and filesystem contents.

Then inspect your container build pipeline. Search image history and config metadata for tokens, credentials, private URLs, and build arguments. In Docker and BuildKit environments, use secret mounts instead of ARG or ENV for sensitive values. The test is simple: build a representative image in a non-production pipeline, inspect the resulting image config and history, and verify that no secret-like values are present.

Finally, audit package publishing tokens. Ask three questions for each token: what packages can it publish, can it bypass MFA, and where is it stored? A CI token with unscoped write access and 2FA bypass is a high-value non-human identity. If possible, scope tokens to specific packages, rotate them aggressively, monitor publish events, and require provenance or trusted publishing workflows where your ecosystem supports them.

Detection ideas without going overboard

A useful detection strategy would look for movement between layers. Watch for sandbox runtimes opening /proc/self/mem, reading /proc/self/maps, or spawning unexpected shell commands. Monitor unusual ECR enumeration from roles that normally only execute narrow workloads. Alert when CI or runtime roles call BatchGetImage and GetDownloadUrlForLayer across many repositories.

On the software supply-chain side, monitor package publish events from CI identities, especially new versions with install scripts, changed maintainer metadata, or publishes outside expected release windows. For frontend packages loaded into authenticated applications, treat publish rights as production-impacting access, not merely developer tooling access.

The bigger lesson

Zapocalypse is a clean example of why non-human identities deserve the same threat modeling energy as user accounts. The critical actor in this chain was not a human admin clicking the wrong button. It was a trail of automation identities: a Lambda role, an ECR access path, a CI npm token, and a package consumed by production systems. That is where many organizations are still soft. Human access gets SSO, conditional access, device posture, MFA, and quarterly review. Machine access gets long-lived tokens, vague ownership, broad package scopes, and permissions nobody wants to break because the pipeline is important.

The fix is not one magic control. It is boring in the best way: stronger sandbox isolation, least-privilege roles verified by behavior, secret-safe build patterns, scoped publishing tokens, package provenance, artifact scanning, and monitoring that follows identities across system boundaries.

For red teams, the useful move is to model these paths before attackers do. Do not just ask, “Can I break out of the sandbox?” Ask what the sandbox can see after breakout. Do not just ask, “Can this role administer AWS?” Ask whether it can read artifacts that contain deploy secrets. Do not just ask, “Can this token publish a package?” Ask where that package runs and whose session it can influence.

Zapier fixed the reported chain. The broader pattern is still everywhere.

Sources

Main source: Token Security, “Zapocalypse: The Attack Chain That Could Have Hijacked Zapier” https://www.token.security/blog/zapocalypse-the-attack-chain-that-could-have-hijacked-zapier

Supporting source: Help Net Security, “Zapier exploit chain shows how known anti-patterns compose into critical risk” https://www.helpnetsecurity.com/2026/05/28/token-security-zapier-exploit-chain/

Feature image: Pexels photo by Markus Spiske https://www.pexels.com/photo/technology-computer-desktop-programming-113850/