Researchers discover an exploit chain combining over-permissioned roles, secrets discovery, and non-human identities that could have compromised a popular automation service. Low-code cloud services that allow users to create and run their own sandboxed code could be compromised by multistep exploit chains, leading to a complete platform takeover, if software-as-a-service (SaaS) providers haven't properly sandboxed their environments, managed the roles and permissions of non-human identities, and inadvertently exposed secrets in code artifacts. Such a compromise almost happened to low-code automation service Zapier. Using a handful of steps that exploited the company's platform, researchers with agentic-identity security firm Token Security discovered they could reconnoiter Zapier's sandboxed environment, discover credentials, and move laterally to pull the company's private repositories, and potentially could have published malicious code, researchers stated in an analysis published May 28. Token Security researchers could have pushed malicious code to Zapier's repositories and to any users authenticated to the system, says Yair Balilti, research team lead for Token Security. Related: Microsoft Issues Out-of-Band SharePoint Patch "If you have a user in Zapier, I can take your cookie, send it to an attacker website," he says. "I can use the same cookie and use all the tools that you are using in Zapier. For example, if you have some automation to send email to get to [another service], I can use the same primitive." The ability to jump between cloud components using credentials, development secrets, and non-human identities has become a major source of vulnerability in enterprise cloud usage . Between the disaggregation of software into various cloud services and the accelerating push for agentic AI swarms , SaaS infrastructure is growing more complex and harder to secure. Cybersecurity researchers have already noted that most companies — 56%, in fact — do not have a process in place to track SaaS-to-SaaS connections and integrations. Last year, the threat actor UNC6395, for example, stole data from company's Salesforce instances by abusing OAuth tokens associated with a third-party sales automation app, Salesloft Drift . Token Security's five-step attack chain used to nearly compromise the automation service started with ability to write code in a code block. Zapier and other automation service providers allow users to write their own code to accomplish custom tasks or allow an AI agent to write the code for them. Code by Zapier , for example, allows customer scripts and data manipulation code to be written in Python and JavaScript. "It is advertised as a place where users run their own logic," Token Security's Balilti stated in his online analysis . "So we ran our own logic." Related: Microsoft Exchange Zero-Day Under Attack, No Patch Available Using their own code, the researchers were able to query the sandbox OS to discover it was running on AWS Lambda, and while there were no obviously leaked credentials, the ability to read a task file showed an overly permissive role — incorrectly named "allow_nothing_role" — and the failure to securely delete credentials. In the file's comments, a developer wrote: > # note - this isn't a security thing since we pass a allow\_nothing role - just avoids

responding to dozens of annoying false positive security reports

As their second step, the researchers created a Python script to extract secrets from the memory, which was aided by the fact that AWS Lambda does not proactively delete the tokens and other secrets until the container is recycled. Using the role, the researchers discovered that they could list and request 1,111 files from Zapier's private repository during the third stage of their attack. Among those files, they found one that exposed an NPM token for publishing that could be used for every package. The Five Stages of Cloud Compromise include escaping the sandbox, finding credentials and over-permissioned roles, and then moving laterally. Source: Token Security While the researchers described their last two steps, they did not execute them. A post-install script would have allowed them to run arbitrary code by adding it to a legitimate Zapier package, and the fifth stage would allowed them to distribute the code to every authenticated Zapier user's browser. Related: Can Laws Stop Deepfakes? South Korea Aims to Find Out "An attacker would have been able to act as the user inside Zapier: create Zaps, create Tables, create MCP servers, modify existing automations, and use the user's existing connections to third-party services through Zapier's platform," Balilti wrote in the analysis. "Those connections execute server-side. The attacker can drive them by riding the user's session and asking Zapier to do things."

Too Many Permissions, Too Little Security

[...]