Grist Pyodide sandbox escape shows how data planes fail

At a glance

What this is: Cyera shows that a Pyodide sandbox escape in Grist-Core can let a malicious spreadsheet formula become remote code execution across data, credentials, and integrations.

Why it matters: IAM, NHI, and platform teams need to treat formula engines as execution surfaces, because compromise of a data plane can expose secrets and pivot into connected systems.

Context

Grist-Core is a programmable spreadsheet and data workflow platform, so its formula engine is not just document logic but an execution environment. Cyera’s analysis shows that when untrusted formulas run inside Pyodide, a sandbox escape can cross the boundary from cell content to host-level command execution.

That matters because Grist can sit between operational data, integrations, and credentials in both SaaS and self-hosted deployments. Once the execution layer is trusted too broadly, the blast radius is no longer a single workbook or server. It becomes a data-plane governance problem for teams that rely on the platform to mediate sensitive workflows.

The article also shows that this is not an edge-case research curiosity. The same pattern can affect real operational use cases across government, education, and industry, which is why formula execution should be treated as a privileged capability rather than ordinary content rendering.

Key questions

Q: What breaks when spreadsheet formulas can execute code inside a data platform?

A: The assumption that formulas are just content breaks first. Once a formula engine can reach host runtime primitives, the platform stops being a document processor and becomes an execution environment with access to secrets, files, and integrations. That changes the control model from content review to runtime governance, because the blast radius now includes connected systems.

Q: Why do programmable data platforms create outsized security risk?

A: They sit between users, data sources, and automations, so they inherit trust from multiple directions at once. If a formula engine or workflow layer escapes its sandbox, the compromise can expose credentials and downstream services, not just a single file. The risk grows when the platform is allowed to mediate sensitive operational workflows.

Q: What are the signs that sandboxing in a data workflow platform is too weak?

A: Look for runtimes that still expose alternate paths to builtins, library loading, or host hooks after the supposed sandbox is applied. If one blocked API is replaced by another route to the same capability, the isolation boundary is brittle. A weak sandbox is one where untrusted formulas can still affect host-level behaviour.

Q: How should teams govern formula execution in collaborative platforms?

A: Treat formula authoring as privileged change activity, not ordinary end-user editing. Separate who can view data from who can define executable logic, and ensure the platform's runtime permissions are narrower than the data it handles. Governance should focus on authoring rights, runtime isolation, and the credentials the platform can reach.

Technical breakdown

How Pyodide sandbox escapes reach host execution

Pyodide runs Python in a WebAssembly sandbox, but sandboxing only holds if the runtime removes or constrains every route to privileged functionality. Cyera shows that Python object traversal can recover access to builtins, while ctypes can expose process symbols that were meant to stay hidden. Once those paths exist, the formula environment stops being isolated and can invoke host capabilities that the platform assumed were unreachable. In practice, the danger is not just code execution. It is the collapse of the boundary between formula evaluation and the underlying runtime.

Practical implication: Treat formula execution as an execution plane, not a content feature, and validate which runtime primitives remain reachable after sandboxing.

Why a data platform becomes a control-plane risk

A programmable data plane sits between users, data sources, and downstream automation, so its formula engine often inherits more trust than a spreadsheet normally should. In Grist, tables, formulas, and automations can interact with operational data and integrations, which means a successful escape may expose credentials, environment variables, or adjacent services. Managed SaaS and self-hosted deployments both inherit this problem, but the SaaS version is especially dangerous because the vendor-operated environment can hold many tenants’ workflows. The technical issue is not only the escape, but the placement of that escape inside a privileged orchestration layer.

Practical implication: Map every formula-capable system to the credentials and integrations it can reach, then reduce that trust boundary before exposure becomes privilege abuse.

Why blocklists fail as an isolation strategy

The report describes a blocklist-style sandbox model, but blocklists are brittle because they try to enumerate what must not happen instead of constraining what can happen. Cyera demonstrates multiple alternate paths to the same outcome: class hierarchy traversal to builtins, ctypes access to libc-style calls, and Emscripten hooks that can execute JavaScript in the host runtime. That means one blocked function does not solve the design problem if the language runtime still exposes equivalent routes. Security assumptions based on a single forbidden API are weaker than capability-based isolation and explicit permission controls.

Practical implication: Prefer capability-based isolation and runtime permission gating over blocklists when untrusted code can execute inside business workflows.

Threat narrative

Attacker objective: Turn a spreadsheet formula into host execution that exposes secrets and opens a path into connected systems.

1. Entry occurs when a malicious formula is processed by Grist's Pyodide-based formula engine inside a vulnerable configuration.
2. Credential or capability access follows when the formula reaches builtins, ctypes, or host runtime hooks that were expected to remain unreachable.
3. Escalation happens when the escaped payload executes OS commands or host JavaScript, exposing environment secrets and adjacent execution paths.
4. Impact is host-level compromise with potential exposure of data, credentials, and downstream systems connected to the Grist environment.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The real failure is trust placed in formula evaluation as though it were harmless content. Grist shows that a spreadsheet formula can become an execution layer when the runtime is permissive enough to recover builtins, call libc, or invoke host hooks. That is not a cosmetic bug in document handling. It is a structural governance failure for platforms that mediate data and automation. The practitioner takeaway is to classify formula engines as privileged runtime surfaces, not as inert inputs.

Capability-based isolation is the only defensible model for programmable data planes. Blocklists cannot keep pace with language features, object traversal, and runtime escape routes. Cyera’s three escape paths show that the question is not whether one function is blocked, but whether the platform still exposes equivalent power through another route. That means teams need a control model built around what code is allowed to do, not around a shrinking deny list.

Data-plane security now includes execution authority, not just data access. When tables, formulas, and automations sit between systems, the platform becomes part of the trust boundary for credentials and workflow logic. Grist is a reminder that an execution-capable data plane can inherit the blast radius of the systems it connects. The practitioner conclusion is to govern these platforms as part of identity and access design, not as passive SaaS storage.

Formula engines deserve the same scrutiny as workflow orchestration and agent runtimes. The difference is not the UI, but whether the platform can turn user-supplied logic into privileged action. Once that is true, the governing question becomes who can author code, what runtime privileges it inherits, and what downstream systems it can touch. Teams should assume the execution surface is part of the control plane unless proven otherwise.

Programmable spreadsheet risk is an identity problem as much as an application problem. If a formula engine can read environment secrets or invoke connected services, the platform has crossed into NHI territory because it is operating with machine-level authority. That means ownership, scoping, and offboarding of the platform's credentials matter as much as patching the runtime. The implication is a tighter join between application security and NHI governance.

What this signals

Programmable data plane risk: Once a workbook can execute logic inside a shared runtime, the platform inherits the trust burden of the systems it connects. That means security teams should map formula-capable products to the credentials, files, and integrations they can touch before deciding whether they belong in sensitive workflows.

The practical lesson is that sandboxing is only as strong as the last reachable capability. If a runtime still exposes object traversal, library loading, or host hooks, then the boundary is already negotiated in the attacker’s favour and not in the platform owner’s favour.

For practitioners

• Classify formula engines as privileged runtimes Inventory every spreadsheet or data platform where user-authored formulas can execute code, call libraries, or touch integrations. Treat those engines as execution surfaces that require explicit governance, not as passive content rendering.
• Validate the patched execution path Confirm that vulnerable deployments are actually running the hardened path and not a weaker compatibility mode that preserves host execution. Test the live configuration rather than relying on version labels alone.
• Restrict formula authoring and modification Limit who can create or edit formulas in collaborative environments, especially where imported documents may carry hostile logic. Separate trusted authors from general editors where the platform can reach sensitive data or services.
• Remove easy access to secrets from execution hosts Keep environment variables, readable configuration files, and other easily exposed secrets out of the runtime path. Reduce what an escaped formula can discover if it crosses into host execution.
• Constrain network reach from the platform Limit outbound and lateral network paths so an escape cannot trivially pivot from the data plane into adjacent systems. Pair runtime hardening with segmentation around the services the platform can reach.

Key takeaways

• Cyera’s findings show that a spreadsheet-style platform can become a host execution layer when formula isolation fails, which changes the security model entirely.
• The issue is not only code execution. It is the potential exposure of environment secrets, adjacent services, and connected workflow systems.
• Teams should govern formula engines as privileged runtimes, limit authoring rights, and reduce the secrets and network reach available to the host process.

Key terms

• 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.
• Data Plane: The data plane is where operational access to content occurs, including prompts, outputs, logs, training data, and secrets. In AI governance, this is the layer where over-privileged identities often expose sensitive information even when the control plane appears tightly managed.
• Capability-based isolation: A design approach that removes dangerous powers from untrusted code rather than trying to block individual risky functions. It is stronger than a blocklist because the runtime simply does not expose the capability needed to spawn processes, reach sensitive files, or call protected services.
• Runtime Permission Model: A runtime permission model controls what a process may read, write, execute, or call while it is running. For formula-driven platforms, this is the difference between harmless computation and host compromise, because permissions determine the true blast radius of a breakout.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.