Zapocalypse — five-stage exploit chain turns a free Zapier account into NPM publish rights on zapier.com's own JS bundle

View raw markdownEdit on GitHub ↗

TL;DR

Token Security chained five separate "known anti-patterns" — sandboxed Python code execution, /proc/self/mem credential recovery, an over-permissioned AWS IAM role, a hardcoded MCP API key, and a leaked NPM publish token — starting from a free-tier Zapier account to reach NPM publish rights on zapier-design-system, a private package that loads in every authenticated zapier.com session. A malicious release would have meant stored XSS → account takeover across Zapier's user base. Reported Feb 12, 2026; fully remediated by Mar 5, 2026; no evidence of in-the-wild exploitation.

What happened

Token Security's research team started from Zapier's "Code by Zapier" feature, which runs user-submitted Python/JavaScript inside AWS Lambda containers in us-east-1, and walked a five-stage chain to full platform compromise:

  1. Sandbox execution confirmed. os.system('env') inside a free-tier Code by Zapier Python block confirmed arbitrary command execution on the underlying Lambda runtime.
  2. Credential recovery from heap memory. Zapier's runtime scrubbed secrets with del os.environ[k] before returning control to user code, but Python's del does not zero the underlying heap allocation. Reading /proc/self/mem and regex-matching for AWS STS token patterns recovered a live, "orphaned" set of session credentials that should have been unreachable.
  3. Lateral movement via an over-permissioned IAM role. The recovered allow_nothing_role credentials — named as if they granted nothing — still permitted enumerating 1,111 ECR repositories and pulling container images directly via the ECR API, bypassing the Docker authentication layer that would normally gate this.
  4. Hardcoded secret in a container image. One pulled image (a customized LiteLLM container) contained a hardcoded Zapier Actions MCP API key, which in turn enabled email impersonation from a LiteLLM co-founder's Gmail account — a second-order credential-hub pivot inside the chain itself.
  5. NPM publish token in image metadata → stored-XSS primitive. The same image layer metadata contained an NPM publish token with "action": "write" and "bypass_2fa": true, granting publish rights to zapier-platform-core, zapier-platform-cli, and — critically — zapier-design-system, a private package whose JavaScript is loaded on every authenticated zapier.com session. Publishing a tampered version would have executed attacker-controlled JS in every logged-in Zapier user's browser: full platform account takeover.

Every individual link (sandbox escape, incomplete secret scrubbing, an IAM role broader than its name implies, a hardcoded key in a container image, a live NPM token sitting in image metadata) is a well-known anti-pattern on its own. The finding is that composing five ordinary weaknesses reached a critical, platform-wide outcome starting from a free account with no special access.

Zapier triaged the report within 4 days (Feb 13), revoked the leaked NPM token and tightened the IAM role by Feb 16, and confirmed full remediation by Mar 5, 2026. The researchers received Zapier's bug-bounty program maximum of $3,000. Zapier states no customer data, credentials, or workflows were accessed, and there is no evidence of exploitation beyond the research itself. No CVE was assigned.

This fits the standing "workflow-automation / iPaaS tools as a credential-hub attack surface" pattern already tracked for n8n (Ni8mare, CVE-2026-21858) — a Code-by-Zapier-class execution sandbox sits in the same position as n8n's workflow engine: one execution environment holding the keys to everything the platform touches, including (here) its own publish pipeline.

Am I affected?

This is a platform-side vulnerability in Zapier's own infrastructure, not something in your dependency tree — there is no local package or lockfile check. If you use Zapier:

# Check whether your project pins zapier-platform-core / zapier-platform-cli
# to a version published between the report window (2026-02-12) and full
# remediation (2026-03-05) — no malicious versions were ever actually published,
# but confirm your pinned versions predate or postdate the window cleanly.
grep -E "zapier-platform-(core|cli)" package.json package-lock.json 2>/dev/null

No malicious package version was ever published — the chain was fully remediated before an attacker (other than the researchers) reached stage 5. There is no IOC or version to rotate away from.

If you are affected

No action is required for Zapier users; the platform-side vulnerability was patched and no malicious release occurred.

If you operate a similar low-code/workflow-automation platform with a hosted code-execution sandbox:

  1. Never rely on del os.environ[...] (or language equivalents) as a secret-scrubbing boundary — heap memory persists until overwritten or garbage-collected. Use processes/containers that are torn down after each execution instead.
  2. Audit IAM role names against actual attached policies — allow_nothing_role-style naming is not a control.
  3. Treat any credential embedded in a container image (env var, config file, or layer metadata) as leaked the moment that image is pullable from any reachable execution context.
  4. See rotating-cloud-credentials.md if you need to respond to a similar chain in your own infrastructure.

Prevention

Sources