Zapocalypse Exploit Chain Could Have Enabled Full Zapier Account Takeover

A newly disclosed research chain called Zapocalypse showed how several security weaknesses could combine into a full Zapier account takeover path. The issue did not come from one simple bug. It came from a chain that moved from a low-privilege code execution feature to cloud credentials, container images, an exposed NPM publishing token, and a potential stored XSS route inside Zapier’s authenticated web app.

Token Security said Yair Balilti, its Security Research Team Leader, will present the research at fwd:cloudsec North America on June 1, 2026. The session will explain how the chain began in a sandboxed Python environment and escalated into what the company described as a full AI platform account takeover scenario.

The important detail is that Zapier says the chain has been fixed. A separate Help Net Security report says Zapier found no evidence that attackers exploited the chain in the wild, and that the research did not access customer data, customer credentials, or customer workflows.

What Zapocalypse Exposed

The chain started in Code by Zapier, a feature that lets users run code as part of an automation workflow. The researchers found that code execution inside the sandbox could still reveal enough about the runtime to begin investigating the surrounding cloud environment.

Zapier’s automation platform runs across a large serverless architecture. An AWS Architecture Blog post from 2025 explains that Zapier uses AWS Lambda to run isolated Zaps and operates more than 100,000 Lambda functions to support customer workflows.

That scale is part of why the finding matters. When automation platforms connect thousands of services, even a narrow runtime weakness can become serious if it touches credentials, build systems, package publishing, or browser-delivered code.

The Zapocalypse Chain at a Glance

Stage	What Researchers Found	Security Impact
Sandbox reconnaissance	Code by Zapier allowed operating system command checks inside the runtime.	Researchers could inspect the Lambda environment and understand its boundaries.
Credential recovery	Orphaned AWS STS credentials remained recoverable from process memory.	Deleting environment variables did not wipe the original bytes from memory.
AWS lateral movement	An IAM role named allow_nothing_role still allowed ECR enumeration and image pulls.	The role exposed enough access to inspect container images through APIs.
Secret exposure	A high-privilege NPM token appeared in container build metadata.	The token had package publishing rights and bypassed two-factor authentication.
Supply-chain risk	The token could publish to packages used by Zapier, including zapier-design-system.	A malicious package update could have created stored XSS in authenticated sessions.

How Memory Scraping Changed the Risk

The first major step involved credential handling inside the Lambda runtime. The research says Zapier removed AWS credentials from environment variables before handing control to user code, but that removal did not erase the underlying bytes from memory.

The attacker model then shifted. Instead of simply reading environment variables, the researchers scanned readable process memory through /proc/self/mem and recovered AWS STS session tokens that had become orphaned in the heap.

Token Security’s announcement says the session will cover why Python’s del keyword does not reliably sanitize sensitive environment variables and how orphaned AWS STS tokens can be extracted from Lambda memory.

The IAM Role Was Named allow_nothing_role, but It Still Allowed ECR Reads

The recovered credentials belonged to an IAM role called allow_nothing_role. Despite the name, the role still permitted several Elastic Container Registry actions, including repository description, image listing, manifest retrieval, and layer download.

That access gave the researchers enough room to pull container images through AWS APIs without using a standard Docker registry authentication flow. The Help Net Security report says the researchers enumerated 1,111 production repositories and pulled images using layer-fetch APIs.

The finding shows why least privilege needs verification, not just naming conventions. A role that appears harmless can still create meaningful access if it has read permissions into sensitive build or runtime artifacts.

The NPM Token Created the Supply-Chain Scenario

The next pivot came from container metadata. Researchers found an NPM publish token in image build history, not in the image filesystem itself. That distinction matters because teams may scan files and still miss secrets stored in build metadata.

The token reportedly had write access and bypass_2fa set to true. According to the research, it could publish to public Zapier developer packages and internal packages, including zapier-platform-core, zapier-platform-cli, and zapier-design-system.

The most sensitive path involved zapier-design-system because it loads inside authenticated sessions on zapier.com. A poisoned package update could have delivered attacker-controlled JavaScript to logged-in users if it reached production.

Why Stored XSS Could Become Account Takeover

Stored XSS inside an authenticated application can let attackers act as the signed-in user in that browser context. In this case, the researchers described a path where malicious JavaScript could interact with Zapier’s interface as the victim.

That would not automatically expose raw OAuth tokens or third-party API keys to the browser. Those secrets remain server-side. However, browser execution inside an authenticated Zapier session could let an attacker create or modify Zaps, Tables, MCP servers, and workflows that use the victim’s existing connected apps.

Zapier positions its platform around automation across more than 9,000 apps, with features such as Zaps, Tables, Agents, Chatbots, and MCP connectivity. That reach explains why a browser-level takeover path could carry serious supply-chain and workflow-abuse risk.

Remediation Timeline

Date	Event
February 12, 2026	Token Security reported the issue to Zapier.
February 16, 2026	Zapier revoked the leaked NPM token and tightened the AWS role.
March 5, 2026	Zapier confirmed full remediation.
May 28, 2026	The research was publicly announced.
June 1, 2026	The research is scheduled for presentation at fwd:cloudsec North America.

The timeline suggests a fast response after the report. Researchers received the maximum $3,000 bounty under the program, and Zapier committed to review that cap at its next program review.

fwd:cloudsec lists its North America 2026 event for June 1 and June 2 at the Meydenbauer Center in Bellevue, Washington. Token Security says Balilti’s session is scheduled for June 1 at 10:50 AM PDT.

No Customer-Side Action Required

Zapier confirmed that the chain did not access customer data, customer credentials, or customer workflows. It also reported no evidence of exploitation outside the research.

That means this disclosure does not require normal Zapier customers to rotate credentials because of Zapocalypse alone. Still, customers should continue to review connected app permissions, audit sensitive automations, and apply least privilege to workflows that can send emails, update records, move files, or trigger business-critical actions.

Zapier’s own product messaging emphasizes governance features such as audit trails, policy controls, and logged AI actions. Those controls become more important as automation platforms handle more sensitive workflows across business apps.

Why This Chain Matters for Automation Platforms

Zapocalypse highlights a broader security issue in no-code, low-code, and AI automation systems. These platforms increasingly act as control planes for business operations. They connect to email, CRM, cloud storage, finance tools, messaging apps, support platforms, and internal APIs.

That makes identity and secret handling more important than ever. A sandbox may look isolated, a cloud role may look narrow, a container image may look clean, and an NPM token may look like a build artifact. The risk appears when all of those pieces connect.

The AWS write-up on Zapier’s Lambda architecture describes the need for cross-tenant compute isolation because Zaps created by users implement tenant-specific business logic. Zapocalypse shows why isolation also needs careful credential lifecycle controls and strong supply-chain boundaries.

What Defenders Should Learn From Zapocalypse

• Do not rely on deleting environment variables as a complete secret-scrubbing control.
• Assume secrets may persist in process memory unless they are explicitly overwritten or isolated.
• Audit serverless runtimes for access to /proc/self/mem and similar memory inspection paths.
• Review IAM roles by effective permissions, not by role names or intended purpose.
• Scan container image metadata and build history, not just the filesystem.
• Avoid passing sensitive build secrets through Docker ARG or ENV when safer secret mechanisms exist.
• Require strict package publishing controls, token scoping, 2FA enforcement, and release signing.
• Track which internal frontend packages load in authenticated user sessions.

The broader lesson is simple: platform-wide risk often comes from composition. Each individual weakness may seem manageable. Together, they can create a path from low-privilege code execution to supply-chain reach.

fwd:cloudsec North America will give researchers a venue to explain the chain in more technical detail. For security teams, the case already offers a useful checklist for reviewing automation platforms, AI code blocks, serverless environments, build pipelines, and package publishing workflows.

FAQ