Low-code cloud services that allow users to run custom code require rigorous execution isolation. If software-as-a-service (SaaS) providers do not fully isolate their sandboxed environments, continuously manage the permissions of non-human identities, and secure their code artifacts, organizations risk unauthorized access to their broader platforms.
This complex relationship between custom code and cloud architecture was recently documented by researchers at the security firm Token Security. During an evaluation of Zapier, a popular automation platform, the research team identified a five-stage assessment sequence. This sequence allowed them to map Zapier's sandboxed environment, locate residual credentials, move laterally to retrieve private repositories, and identify a path that could have support the distribution of unauthorized JavaScript.
Token Security published their analysis on May 28, 2026, noting that this specific finding could have allowed an unauthorized party to impersonate users within the platform. According to Yair Balilti, research team lead for Token Security, an unauthorized party could theoretically take a user's session cookie, send it to an external server, and reuse it to manage that user's established integrations. This access executes server-side, meaning the threat actor could drive the connections by riding the user's session.
The ability to pivot between cloud components using development secrets and non-human identities is an emerging challenge in enterprise cloud architecture. As software disaggregates into interconnected SaaS services and AI-driven autonomous workflows expand, cloud infrastructure requires highly precise security configurations. Industry data indicates that 56% of companies lack a formal process to track SaaS-to-SaaS connections. Threat actors actively evaluate these connections; last year, the threat actor designated UNC6395 accessed data in Salesforce instances by abusing OAuth tokens tied to a third-party sales automation application, Salesloft Drift.
The assessment sequence
Token Security’s five-step evaluation focused on Zapier's "Code by Zapier" feature, which allows users to write custom Python or JavaScript for data manipulation.
In the first stage, researchers tested the environment boundary. Using basic Python commands, they verified that the os.system function was active and determined the code was running on AWS Lambda (python3.11 in the us-east-1 region). While evaluating the local directory (/var/task), they found an overly permissive IAM role named allow_nothing_role and discovered that credentials were not securely scrubbed from memory.
A developer comment in the platform's code noted the design assumption:
# 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
The second stage of the evaluation examined memory allocation. Zapier's code attempted to remove AWS credentials by executing del os.environ[k]. However, in Python, this command removes the variable reference but does not overwrite the bytes in memory. Because AWS Lambda utilizes warm-starts—keeping containers active for subsequent invocations—the credentials remained in the memory heap. Researchers wrote a script to read /proc/self/mem and successfully extracted STS tokens.
Using these residual credentials and the allow_nothing_role, the researchers advanced to the third stage. They listed and requested 1,111 files from Zapier’s private Elastic Container Registry (ECR). Among the retrieved data, the fourth stage revealed a high-privilege NPM token left in the container build metadata.
For the fifth stage, the researchers identified that this NPM token granted publishing rights to zapier-design-system, a private package loaded into every authenticated Zapier user's browser. While Token Security did not execute this final step, possessing this token could have allowed an unauthorized party to distribute altered code to users, enabling them to create Zaps, build Tables, or modify automations on behalf of those users.
Prompt remediation and identity governance
Token Security reported the finding to Zapier on February 12, 2026, adhering to responsible disclosure practices. Zapier acknowledged the report within hours, revoked the exposed NPM token, and restricted the ECR role by February 16. Zapier confirmed full remediation by March 5 and awarded the program's maximum bounty of $3,000, while also committing to review the bounty cap. Token Security plans to present these findings on June 1 at fwd:cloudsec North America.
This finding highlights the necessity of strict identity governance. Balilti advises organizations to verify the access levels granted to their automation platforms. When connecting tools like Salesforce, Gmail, or Google Drive to an automation workflow, teams should configure those integrations with the least-privileged scope possible. Ensuring that automated access is restricted to specific resources or read-only modes limits the potential impact if a session is ever compromised.
The challenge of permission management is widespread across the industry. In March 2026, Salesforce issued warnings to customers regarding overly permissive guest account configurations that help social-engineering efforts and unauthorized data access.
Because many automation platforms feature similar custom code blocks, threat actors are likely testing these integration points across various SaaS deployments. Securing these environments requires providers to continuously evaluate their sandbox architectures and mandates that organizations actively audit the privileges granted to their non-human identities.