Grist Pyodide sandbox escape shows how data planes fail

At a glance

What this is: Cyera Research Labs found a Pyodide sandbox escape in Grist-Core that can escalate a spreadsheet formula into host-level remote code execution.

Why it matters: IAM and security teams should treat formula engines as privileged execution surfaces because a single sandbox failure can expose secrets, integrations, and adjacent systems across NHI and workflow governance.

👉 Read Cyera's analysis of the Grist Pyodide sandbox escape and blast radius

Context

Grist-Core is a programmable spreadsheet and data workflow platform, which means its formula engine sits closer to application logic than to a simple document viewer. In that model, non-human identity concerns appear when formulas can reach host capabilities, because data processing starts to behave like execution.

The primary governance problem is the assumption that untrusted spreadsheet content stays confined inside a safe runtime. Once that assumption fails, NHI-style blast-radius thinking applies to credentials, APIs, and downstream systems tied to the platform. For background on how identity and access controls need to change around shared non-human execution surfaces, see the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

Key questions

Q: What breaks when spreadsheet formulas can reach host execution?

A: The spreadsheet stops being a content container and becomes an execution surface. Once formulas can call host primitives, the attacker can reach files, environment secrets, and network resources tied to the runtime. That is why the control boundary must sit around the formula engine itself, not around the document format. Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs helps teams think about lifecycle and privilege scope around non-human execution.

Q: Why do sandbox escapes create such a large risk in data workflow tools?

A: Because these tools often sit between business data, SaaS integrations, and privileged credentials. When the sandbox fails, the compromise is not limited to the formula result. It can expose secrets, enable command execution, and open paths into systems the platform already trusts. The risk grows with every integration and every secret reachable from the runtime.

Q: How do security teams know if a formula engine is too privileged?

A: Look for three signals: reachable host commands, access to runtime libraries or embedded hooks, and network or filesystem paths that exceed the platform’s business need. If any of those are present, the formula engine is operating like a privileged service rather than a bounded calculation layer. That is a governance problem, not just a code issue.

Q: What should teams do first after a formula sandbox escape is disclosed?

A: Prioritise containment before broadening use. Patch or disable the vulnerable execution path, revoke exposed credentials, confirm which deployments are affected, and remove any secrets or integrations the runtime should not have been able to touch. Then reassess who is allowed to author formulas and how much trust the workflow tool is given.

Technical breakdown

Pyodide sandbox boundaries and why blocklists fail

Pyodide runs Python in a WebAssembly sandbox, but isolation depends on what the runtime still exposes through Python internals and embedded host interfaces. A blocklist can hide obvious imports and still leave enough object-model access to reach builtins, libraries, or runtime helpers. That is why sandboxing formula engines is hard: the attack path does not need a direct import if the interpreter still contains alternative reachability paths. In Grist, the formula layer is not just data transformation. It is code execution with a boundary that must be capability-based, not cosmetic.

Practical implication: treat formula execution as a privileged runtime and verify which capabilities remain reachable after sandboxing.

How host command execution emerges from formula logic

One escape path uses Python object hierarchy traversal to recover __builtins__ and reach os.system(), which turns a cell formula into OS command execution. Another uses ctypes.CDLL(None) to call exported C symbols in the runtime, including system(). These are different routes to the same outcome: the sandbox blocks the obvious path but leaves alternate language features intact. Once those primitives are available, the spreadsheet is no longer the security boundary. The host process becomes the target, and any secrets or local resources available to that process become in scope.

Practical implication: restrict formula authorship and assume any reachable host primitive converts spreadsheet data into an execution vector.

Why SaaS deployment expands the blast radius

In a managed SaaS, the execution surface lives inside a vendor-operated control plane that may hold tenant data and workflow credentials. That changes the consequence of a sandbox escape from local compromise to multi-tenant data-plane risk. The same applies on-prem when the service account, environment variables, and network reach are broader than they need to be. The real architecture issue is not only whether the sandbox fails, but what that runtime can already touch. A formula engine connected to secrets and integrations is a trust hub, not a passive document parser.

Practical implication: reduce runtime privileges, isolate secrets from the execution host, and limit network paths from formula engines.

Threat narrative

Attacker objective: The attacker wants to turn a spreadsheet formula into host execution and use that foothold to reach secrets and nearby systems.

1. Entry occurs when a malicious formula is delivered into a vulnerable Grist deployment and evaluated by the Pyodide runtime.
2. Credential or capability access follows when Python internals or ctypes expose host functions such as builtins, libc calls, or Emscripten runtime hooks.
3. Impact lands as host-level remote code execution with access to files, environment secrets, and potential pivot paths into adjacent systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Formula engines are part of the execution plane, not just the data plane. The moment a spreadsheet evaluates untrusted logic, it inherits the same governance burden as any privileged runtime. Cyera’s findings show that a document boundary can hide a code-execution boundary, which means shared workflow systems must be assessed as identity-adjacent execution surfaces, not as content repositories. Practitioners should classify formula authoring, formula evaluation, and connected integrations as one trust zone.

Capability-based isolation matters more than simple sandbox branding. A sandbox that still permits object traversal, host symbol access, or embedded runtime hooks is only partially isolated. The failure mode here is not abstract weakness, but reachable execution primitives that survive the filter layer. That is why capability review must ask what the runtime can still call, load, or export after filtering, not whether the interface claims to be sandboxed. Teams should validate actual runtime reachability, not just platform labels.

Identity blast radius is the right concept for spreadsheet-driven workflows. The named concept here is the identity blast radius: the set of credentials, data paths, and downstream services that become reachable when a trusted execution surface is compromised. In Grist-like systems, that blast radius can include environment variables, API keys, SaaS integrations, and adjacent services trusted by the platform. The implication is that workflow tools need the same least-privilege scrutiny applied to other non-human identities.

Self-hosted and SaaS deployments fail in different places, but the governance problem is the same. In self-hosted environments, local permissions and exposed secrets define the blast radius. In SaaS, tenant isolation and vendor control-plane exposure matter just as much. The security question is not where the software runs, but what the formula runtime can reach once it escapes its intended boundary. Practitioners should judge both deployment models by the privilege they grant to the execution layer.

The control failure is trust without containment. The platform was trusted to process user formulas while the runtime still had enough reach to become a host compromise path. That assumption breaks the moment untrusted data can trigger commands, load libraries, or call host runtime functions. The discipline lesson is straightforward: if a workflow engine can execute, it must be governed like a privileged service account with a tightly bounded scope.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which shows the issue is already operational rather than hypothetical.
• Ultimate Guide to NHIs , Regulatory and Audit Perspectives helps teams translate runtime exposure into audit-ready governance controls.

What this signals

Identity blast radius: workflow platforms now need to be assessed by what their execution layer can reach, not by what their user interface suggests. The practical question is whether one formula can touch credentials, adjacent systems, or sensitive files before containment kicks in. That shift aligns naturally with the NIST Cybersecurity Framework 2.0 idea of reducing impact through stronger protection and response boundaries.

Cyera’s findings reinforce a broader programme lesson: trust in non-human execution should be measured by reachable privilege, not by deployment label. A managed service can still carry SaaS control-plane risk if its runtime touches tenant data and integration credentials, which is why teams should map formula engines into their NHI inventory and review them as privileged workloads. For deeper context, the Top 10 NHI Issues remains the most practical starting point.

The signal for practitioners is that data tools with embedded compute will keep accumulating identity-like risk because they bridge content, automation, and access. That means governance must move upstream, before the workflow engine is allowed to handle secrets or call external systems, rather than waiting for a vulnerability to force the issue. The organisations that do this well will treat runtime containment as part of identity design, not as an afterthought.

For practitioners

• Map formula execution as a privileged workload Inventory every workflow or spreadsheet platform that evaluates user-supplied formulas, then document which host capabilities, file paths, and network destinations the runtime can still reach.
• Remove easy-access secrets from execution hosts Move API keys, tokens, and service credentials out of environment variables and readable config files wherever the formula runtime can touch them.
• Constrain authorship and modification rights Limit who can create or edit formulas in collaborative workspaces, and treat imported documents as potentially hostile until they pass review.
• Validate the patched execution path in production Confirm that the deployment is using the intended isolated runtime path and that weaker fallback modes are disabled for untrusted or semi-trusted formulas.
• Reduce network reach from data-plane tools Apply egress controls so a compromised formula engine cannot pivot into adjacent internal systems or SaaS integrations with broad trust relationships.

Key takeaways

• A spreadsheet formula can become a host execution path when sandbox boundaries still expose runtime capabilities.
• The risk is not confined to one server because workflow platforms often sit next to credentials, integrations, and downstream systems.
• Practitioners should govern formula engines like privileged non-human workloads and shrink their reachable blast radius immediately.

Key terms

• Formula Engine: A formula engine is the runtime that evaluates user-authored expressions inside a business application. In a spreadsheet platform, it may transform data, call functions, and interact with supporting libraries, which means it must be governed as code execution whenever untrusted input is allowed.
• Sandbox Escape: A sandbox escape is when code breaks out of its intended isolation boundary and gains access to host capabilities. In identity terms, it turns a constrained non-human execution path into a privileged runtime that can touch files, secrets, or downstream systems.
• Identity Blast Radius: Identity blast radius is the set of credentials, data paths, and connected systems that become reachable if a trusted non-human workload is compromised. The smaller the blast radius, the less far an execution failure can propagate across environments and integrations.

Deepen your knowledge

Formula engines as privileged non-human workloads are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you manage workflow platforms, this is the right place to build a governance baseline around runtime privilege and blast radius.

This post draws on content published by Cyera: Cellbreak, Grist’s Pyodide Sandbox Escape and the Data-at-Risk Blast Radius. Read the original.