Zapier security chain exposed package publishing risk

Token Security researchers disclosed a security chain in Zapier that led from its Code by Zapier feature to write access on Zapier-maintained NPM packages. They reproduced the issue through four stages before it was remediated.

The findings describe a five-stage path that began with user-supplied code running inside AWS Lambda containers and progressed through recovered cloud credentials, access to container images, and an exposed publishing token. The final stage, which was identified but not carried out, would have involved publishing altered code to a package loaded in authenticated Zapier browser sessions.

The attack path required only a free Zapier account as its starting point and linked together several known weaknesses rather than relying on a single novel flaw.

In the first step, code run through Zapier's code execution feature escaped its intended sandbox and gained access to the underlying Lambda environment, including environment variables, the file system, and process data. The second step involved recovering AWS credentials from process memory after they had been removed from environment variables.

Those credentials then allowed access to an AWS role called allow_nothing_role. Despite its name, the role gave read access to 1,111 production Elastic Container Registry repositories, exposing container images used across Zapier systems.

From those images, the team found a GitLab CI token used to publish Zapier's NPM packages. The token had package write access, null scope, and bypass_2fa set to true, which would have allowed changes to be published to any Zapier-maintained package.

One package cited in the research was zapier-design-system, which is loaded in authenticated Zapier web sessions. A malicious patch to that package could have executed JavaScript in the browser context of logged-in users, letting an attacker act as those users inside the platform.

That could have enabled actions such as creating Zaps, Tables, and MCP servers, as well as using a victim's existing integration connections through Zapier. Browser-side session harvesting was not demonstrated, and underlying OAuth credentials for connected services remain on the server side.

Scope of exposure

The report frames the issue as a non-human identity problem spanning several systems. It points to three machine identities in particular: a Lambda execution role, an MCP API key, and an NPM CI token.

The main risk was not confined to Zapier's platform, but extended to any authenticated user account and the external software services those users had connected through automation workflows. Because Zapier sits between a large number of SaaS products, a compromised user session could have broad downstream reach even without exposing raw credentials.

Separate from the main package-publishing chain, the research also described an MCP API key found in a private LiteLLM container image in Zapier's registry. According to the account provided, the key was linked to a third-party developer account and was used only to verify that it was live and to send a single email to a controlled inbox.

Response and remediation

Zapier was said to have responded quickly after the issue was reported through HackerOne. The leaked NPM token was revoked immediately, the Lambda IAM role scope was tightened, and broader fixes were later rolled out across the affected systems.

The report said the chain was reproduced under controlled accounts from the initial code block through to package publishing rights. The fifth browser-impact stage was documented but deliberately not executed, and no package was poisoned.

The researchers said they had no evidence of exploitation in the wild, and Zapier had not indicated any. They identified the exposure window as the period between discovery and the first confirmed fixes, while noting that the publishing token itself had originally been issued months earlier.

Lessons for SaaS platforms

Beyond Zapier, the disclosure highlights several recurring security problems in cloud software and supply chains. The researchers said teams should treat user-code features as hostile environments, audit IAM roles by effective permissions rather than names, and avoid passing secrets through Dockerfile ARG or ENV values because they remain visible in image history.

They also urged tighter controls on package publishing tokens, including narrow scope, shorter lifetimes, and no bypass of two-factor checks. Another recommendation was to restrict where recovered cloud credentials can be used from, rather than focusing only on which actions they permit.

The report described the broader weakness in direct terms: "Each link in the chain was a known anti-pattern. The chain itself was the vulnerability," said Yair Balilti, Security Research Team Lead, Token Security.