.gif){kind=logo}
Zapocalypse
How one Lambda memory leak exposed publish capability over Zapier’s NPM supply chain.
A five-stage chain from Code Block sandbox to publish rights over a package running in zapier.com. Each link in the chain was a known anti-pattern. The chain itself was the vulnerability.
What is Zapocalypse?
Zapier’s Code by Zapier feature runs user-supplied Python and JavaScript inside AWS Lambda containers.
A five-stage chain — starting from a straightforward sandbox escape and ending in a supply chain foothold against every Zapier-published NPM package — turned a single Code Block into write access to Zapier’s published NPM packages.
Each link in the chain was a known anti-pattern. The chain itself was the vulnerability. Stages 1–4 were demonstrated end-to-end under coordinated disclosure. Stage 5 was identified but deliberately not executed.
The five-stage chain.
Read left to right. Each stage hands the attacker something the next stage needs. Stage 4 is the inflection point — supply chain takeover of every Zapier-published NPM package.
-
01 Stage 01
Code Block sandbox escape
Break out of the “Code by Zapier” sandbox into the underlying AWS Lambda container running the runtime.
Shell-equivalent access inside the Lambda — environment variables, filesystem, and /proc. -
02 Stage 02
Memory leak via /proc/self/mem
Recover the “deleted” AWS credentials from process heap memory after Zapier’s sanitization runs.
A valid AWS STS session (ASIA key + secret + session token) for the Code Block runtime role. -
03 Stage 03
ECR enumeration via allow_nothing_role
The role named allow_nothing_role allowed plenty — including read access to 1,111 production ECR repositories.
Pull access to Zapier’s full container image catalog. Read-only source to their backend services. -
★ Core finding
04 Stage 04
NPM supply chain takeover
A GitLab CI token used to publish Zapier’s NPM packages — leaked through a Dockerfile ARG baked into image build history — could grant write access to every Zapier-maintained NPM package, with bypass_2fa and null scope.
Write access to publish a malicious patch of any Zapier-maintained NPM package into zapier.com’s production bundle. -
Theoretical · Not executed
05 Stage 05
Browser-side impact
A poisoned patch of a package already loaded in zapier.com (load path verified in DevTools) could execute attacker JavaScript in the browser context of logged-in users.
An attacker could act as the user inside Zapier — creating Zaps, Tables, and MCP servers, leveraging that user’s existing integration connections. Browser-side session harvesting was not demonstrated.
Credential & access propagation.
Impact & blast radius.
Who is exposed, what an attacker gains, and why it scales fast.
Via the AWS role literally named allow_nothing_role. Effectively read-only source for Zapier’s backend services.
GitLab CI token used by Zapier’s NPM publishing pipeline. Write access to every Zapier-maintained package. Baked into image build history via a Dockerfile ARG.
Loaded in every authenticated zapier.com session — load path verified live in DevTools. With Stage 4 write access, an attacker could publish a poisoned patch; internal consumers would need to pull and deploy the new version before it reached production.
What an attacker reaching Stage 4 could do
- Publish a malicious patch version of any Zapier-maintained NPM package
- Have it deployed into the production zapier.com bundle on the next release
- Execute attacker JavaScript in the browser of every authenticated Zapier user
- Act as any authenticated user inside Zapier — creating Zaps, Tables, and MCP servers, leveraging that user’s authorized integrations
- Pre-condition for the entire chain: a free Zapier account — no paid tier, no special role, no prior foothold
Mitigations for defenders.
Concrete steps for any team running a SaaS automation platform — or building on one.
Treat user-code features as hostile execution environments
If your platform lets users run Python or JavaScript, assume sandbox escape. Defense-in-depth at the IAM, network, and runtime layers — not at the language layer. Sandboxes leak; perimeters should not.
runtime · sandboxingAudit IAM roles by what they can do, not what they’re named
A role named allow_nothing_role granted read access to 1,111 production container images. Names are documentation; policies are enforcement. Use AWS IAM Access Analyzer to generate least-privilege baselines from real CloudTrail usage, iam:SimulatePrincipalPolicy to test specific actions against the actual policy. Audit every role attached to user-code workloads — trust the policy, not the label.
IAM · least privilegeDockerfile ARG is not a secret store
Anything passed via ARG or ENV in a Dockerfile lives forever in the image’s history[] field, readable by anyone with pull access. Use BuildKit secrets (--mount=type=secret) for build-time credentials so they never land in a layer. Audit existing images or fetch config.json directly from the registry via the OCI distribution API and grep the history[] field for token-shaped strings.
supply chain · buildScope NPM and package-registry tokens aggressively
The token that made this chain end-to-end had package:write at null scope and bypass_2fa:true. That’s a supply chain weapon, not a CI credential. For automation tokens: use NPM granular access tokens scoped per-package, set short TTLs and rotate aggressively, restrict by IP when the registry supports it, and never set bypass_2fa. For publishing, prefer npm provenance over long-lived tokens.
npm · CI tokensConstrain where credentials work, not just what they can do
The STS credentials recovered from Lambda memory worked from anywhere — we used them from our own machine to enumerate ECR and pull 1,111 production images. The Lambda itself never reached ECR; the credentials escaped, and we did. Add IAM condition keys like aws:SourceIp or aws:VpcSourceIp so role credentials are only usable from the expected network. Enable GuardDuty’s UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding to alert when role credentials are used from outside your AWS accounts. Either control would have caught this chain on the first ECR call from our laptop.
IAM · containmentInventory your non-human identities end to end
This chain stitched together three non-human identities across three systems: a Lambda execution role, an MCP API key embedded in a third-party container, and an NPM CI token leaked through Dockerfile metadata. None were exotic. All were long-lived, broadly scoped, and unmonitored. Concrete actions: inventory every NHI across cloud, SaaS, and source-control systems; assign each one an owner and an expiration; alert on long-lived credentials that never rotate; treat third-party container images as an NHI source, not just code.
NHI · governanceDon’t rely on language-level deletion for secrets in memory
del os.environ[k] removes a Python dict reference — it does not zero the underlying bytes in process heap. The Lambda runtime “sanitized” credentials this way, and /proc/self/mem recovered them anyway. For workloads that handle credentials, fetch secrets just-in-time from STS, Secrets Manager, or Parameter Store with short-lived credentials rather than relying on injected env vars that need to be “removed” before user code runs. If you must scrub env vars, do it in the runtime layer before the user-code container is reachable.
runtime · secretsWatch the seams between systems, not just inside them
No single Zapier system was catastrophic on its own. The chain composed Lambda, ECR, GitLab CI, NPM, and the browser. Map the lateral edges between systems where one identity hands off to another; that is where supply chain takeovers live. A free account is enough — assume the perimeter has already been crossed.
posture · lateralDisclosure timeline.
Coordinated disclosure via HackerOne.
-
2026 · 02 · 10Research begins
Initial sandbox escape and memory recovery against Zapier’s Code Block. The first three stages of the chain come together in days.
-
2026 · 02 · 12Reported to Zapier via HackerOne
Full chain reproduced under controlled accounts. Stages 1–4 demonstrated end-to-end; Stage 5 documented as theoretical, not executed.
-
2026 · 02 · 16Zapier triages within 4 days
Zapier revokes the leaked NPM token immediately and tightens the Lambda IAM role scope. Triage was fast and substantive.
~4 days from report (Feb 12) to triage -
2026 · 03 · 05Initial fix shipped
First round of fixes deployed. Broader hardening across the affected surfaces continues.
-
2026 · 04 · 30Public disclosure approved
Zapier approves coordinated public disclosure timed to fwd:cloudsec NA 2026. Embargo set.
-
2026 · 06 · 01Public disclosure — fwd:cloudsec NA 2026
Full talk and this microsite published at fwd:cloudsec NA 2026 in Bellevue, WA. ~80 days from report to public disclosure. Zapier engaged seriously and effectively throughout.
fwd:cloudsec NA · Mon Jun 1, 10:50 AM
Questions you’ll have.
Click any question to expand.
Is my organization impacted?
Zapier has confirmed no evidence of exploitation of this chain in the wild beyond the research itself. The chain did not access customer data, customer credentials, or customer workflows, and was fully remediated under coordinated disclosure. No customer-side action is required.
Has this been exploited in the wild?
We have no evidence of exploitation, and Zapier has not indicated any. The chain was discovered, reported, and fixed under coordinated disclosure before any public details existed.
Has Zapier fixed it?
Yes. Zapier triaged the report within four days of submission, revoked the leaked NPM token immediately, tightened the Lambda IAM role scope, and shipped broader fixes. The full timeline is above.
What about Stage 5 (browser-side impact)?
Stage 5 was not executed. We verified that the package targeted by Stage 4 (zapier-design-system) loads in every authenticated zapier.com session — confirmed live in DevTools — but we did not publish a poisoned version. An attacker with Stage 4 access could execute JavaScript in a user’s browser context, allowing them to act as that user inside Zapier. Browser-side session harvesting was not demonstrated, and OAuth credentials for connected integrations remain server-side. Stopping at write access to a production package, and reporting it, was the responsible line.
How does this relate to NHI (non-human identity) security?
Every stage of this chain was a non-human identity problem. A Lambda execution role with quiet over-permissions. A long-lived MCP API key hardcoded into a third-party container. An NPM CI token with bypass_2fa and null scope, leaked through a Dockerfile ARG.
None of these were user-credential bugs — they were identities for machines, services, and pipelines, all long-lived and broadly scoped. That category of identity is where this kind of chain breaks, and where it gets fixed.
Who found Zapocalypse?
Token Security Research. More of our work is published at token.security/research.
Where can I see the full technical details?
The full walkthrough is presented at fwd:cloudsec NA 2026 on Monday, June 1, 2026 at 10:50 AM, in Bellevue, WA. Slides and recording will be linked here after the talk.
Was this research authorized?
Yes — the research was conducted within Zapier’s HackerOne bug bounty program scope. The chain was reproduced under controlled accounts we created for the research. The leaked MCP key tied to a third-party developer’s Zapier account was used only to verify the key was live (sending a single email to ourselves) and to enumerate the available tools — no third-party data was accessed, modified, or exfiltrated.
Why disclose this publicly?
Because the patterns that made this chain possible — leaky sandboxes, misleading IAM names, Dockerfile ARG abuse, over-scoped NPM tokens — exist in many other platforms. Defenders learning from this disclosure can audit their own environments before someone else finds the same patterns there. Zapier supported coordinated disclosure for exactly this reason.
Is there a CVE?
No CVE was assigned. The vulnerabilities were disclosed and remediated under Zapier’s HackerOne bug bounty program rather than through a public CVE process.
Speaker & talk.
Yair leads security research at Token Security, focused on non-human identity, AI agent attack surfaces, and cloud platform vulnerabilities. His work targets the seams between identity, automation, and supply chain — the places where a single misconfigured credential becomes a chain.
With research support from the Token Security research team. Explore Token Research
