Weird Machine combinator: leveraging AI orchestration at the expression layer

This paper attempts to address the problem that expression sandboxes in AI orchestration platforms fail to provide an effective security boundary, leading to credential leakage and system takeover.

• Scenario and importance: In modern workflow automation and agentic AI orchestration platforms, systems widely use expression engines to evaluate user-supplied expressions; meanwhile, credential stores, expression engines, and execution runtimes coexist in a single process or the same trust domain, so sandbox escape is equivalent to full compromise of the credential store.
• Shortcomings of existing approaches: Existing orchestration platforms commonly adopt "enumerate-and-block" schemes based on AST rewriting, runtime property blacklists, and template sandboxes; the author points out that this approach is structurally unfixable because the ever-expanding language specification means blacklists can never be complete, and it cannot defend against compile-stage escapes.
• Core observation and hypothesis: The author proposes that expression sandboxes are essentially weird machines, whose instruction set is the underlying language specification, and the defender's blacklist is merely an incomplete enumeration of that specification; when evaluation stages in a pipeline combine, they erase taint through trust laundering, producing emergent computations that do not exist at any single stage.
• Proposed solution: The paper provides empirical evidence through three rounds of bypasses against n8n, proposes three extensions to the weird machine framework, develops an AST coverage quantification analysis method and automated tool, and proposes a defense playbook centered on minimal allowlists (policy inversion) and process-level runtime isolation.
• Threat model:
  • Attacker goal: Achieve remote code execution (RCE), read encryption keys from process environment variables, decrypt and tamper with the credential store, and persistently intercept all API calls to external systems such as AI service providers.
  • Attacker knowledge and capability: Divided into two categories: an authenticated attacker requires no admin privileges, only ordinary workflow editing permissions, and their actions are indistinguishable from normal workflow authoring; an unauthenticated attacker requires no account or authentication, only network access to a public form endpoint (such as /form/*).
  • Victim system: Orchestration platforms where the expression engine, credential store, and workflow execution runtime coexist in a single process or a single trust domain (e.g., n8n).

In related work, the author focuses on three groups of work and clarifies the baseline and positioning of this paper:

• Weird Machines Theory: Bratus et al. (2011, 2014) and Shapiro et al. (2013) formalized the concept of weird machines, defining them as the gap between the programmer's expected computation and actual computation, used to explain low-level vulnerabilities such as buffer overflows, format strings, and ROP chains. The author notes that classic weird machines have a fixed instruction set and run on a single computational substrate, whereas orchestration-layer weird machines have dynamically evolving instruction sets and combine across processing boundaries.
• Language and Template Sandboxing History: OpenJDK JEP 411 (2021) documents the deprecation of Java SecurityManager in Java 17 due to its long-standing "escape-patch-escape" cycle; vm2 was deprecated in 2023 after repeated escapes and was bypassed again in 2026 (CVE-2026-22709). Jinja2's SandboxedEnvironment was bypassed again by CVE-2025-27516 via the |attr filter after the CVE-2024-56326 fix; expr-eval, a safe expression evaluation library used in LangChain.js, was disclosed with CVE-2025-12735. The author uses this to argue that enumeration-blocking sandboxes have an unfixable lifecycle trajectory.
• Orchestration and CI/CD Injection Research: Poutievski (2021) and Ilgayev (2023) analyzed ${{ }} injection vulnerabilities in GitHub Actions; the author points out that ${{ }} injection in CI/CD pipelines and expression injection in orchestration platforms belong to the same vulnerability category. For n8n, independent researchers reported CVE-2025-68613, JFrog (Nehorai, 2026) reported CVE-2026-1470 (exploiting the with statement) and CVE-2026-0863 (exploiting Python attribute introspection); Retool (2025) disclosed an architectural vulnerability where the sandbox and credential encryption keys share a process; Bargury (2022) discovered the ZAPESCAPE vulnerability in Zapier exploiting shared Lambda models across accounts.
• Baseline methods and benchmarks: The paper analyzes n8n's official expression engine @n8n/tournament (AST rewriting and runtime sanitizers before and after v2.4.0), benchmarking coverage against the 72 AST node types defined by the ESTree specification (ECMA-262 15th edition).

The author positions this paper as: extending weird machine theory from low-level binaries to orchestration systems, proposing three extensions—dynamic instruction sets, compositional weird machines, and trust laundering—and providing an analytical method to quantify AST coverage gaps and a structural policy inversion solution.

The authors propose an orchestration-layer weird machine analysis and defense framework, which quantifies the sandbox attack surface by defining AST-uncovered nodes as the weird machine instruction set, uses LLM-assisted enumeration to generate exploit payloads, and proposes a structural defense system based on policy inversion and runtime isolation.

Orchestration-layer extension and formalization of the weird machine framework

The authors identify three characteristics of orchestration platform expression engines that differ from classic weird machines:

• Dynamic instruction sets: The instruction set of a classic weird machine is fixed by the hardware architecture, whereas the instruction set of an expression engine is the underlying dynamic language specification; as ECMAScript (TC39) continuously introduces new syntax and AST node types, defender enumeration blacklists always lag behind the specification.
• Compositional weird machines: Two individually correct single-stage evaluation logics, when concatenated, can compose malicious computational capabilities that neither stage possesses alone.
• Trust laundering: When input crosses different processing nodes, the system defaults to the next stage inheriting the trust level of the previous stage, thereby stripping taint level by level.

To this end, the authors define the AST specification coverage calculation formula: Coverage Ratio = (|𝒩_handled|)/(|𝒩_spec|) where the numerator is the size of the set of AST nodes explicitly handled by the sandbox, and the denominator is the total number of node types defined by the language specification. For two-stage evaluation, the authors formalize the compositional instruction set as: ℐ_comp = 𝒪_{Pass 1} ∩ ℰ_{Pass 2} That is, the set of inputs that are embedded as literals in the output of the first stage and can be parsed as executable expressions by the second stage.

Expression sandbox bypass mechanism and compile-time escape

For the n8n @n8n/tournament sandbox architecture, the compilation process is: parse expression into AST → VariablePolyfill rewrites dangerous identifiers → compile into dynamic JavaScript function → runtime sanitizer wraps execution. The authors reveal the core mechanism through two groups of bypasses:

• AST rewriting and prototype manipulation (Round 1): Using TaggedTemplateExpression as a property accessor, ArrowFunctionExpression as a this carrier, combined with Error.prepareStackTrace to obtain the CallSite object and execute code; subsequently using Object.defineProperty to manipulate the prototype chain via CallExpression.
• Compile-time escape (Round 2): Constructing {...process} to place the process identifier under the SpreadElement node. Since the VariablePolyfill switch statement only covers 25 types of nodes, not including SpreadElement, the execution flow falls into the default branch executing assertNever(parent) and returning true, causing the rewriting to be completely skipped; the native process identifier directly resolves to the Node.js global object, and then getBuiltinModule is called to obtain child_process to achieve RCE. This exploitation is completed at compile time, rendering all 9 runtime sanitization checks completely ineffective.

Multi-stage evaluation composition and end-to-end attack chain

In the Form node, the authors reveal an unauthenticated double evaluation vulnerability (Round 3):

• First stage (Pass 1): Form.node.ts in getNodeParameter parses the configuration expression, embedding user-supplied form data as literal strings into the HTML content.
• Second stage (Pass 2): utils.ts in prepareFormFields rescans the parsed HTML for {{ }} expression patterns via getResolvables(), and calls evaluateExpression() to execute code.

Based on the above vulnerabilities, the authors design a 6-step end-to-end attack chain:

1. Achieve RCE through expression injection (CVE-2026-27577 or CVE-2026-27493);
2. Read environment variable N8N_ENCRYPTION_KEY;
3. Use OpenSSL-compatible format (AES-256-CBC with MD5 EVP_BytesToKey) to decrypt the credentials_entity database table;
4. Tamper with the baseUrl of AI service provider credentials in the database, pointing to an attacker-controlled transparent reverse proxy;
5. The reverse proxy terminates TLS and forwards requests to the real service provider, intercepting the API key in the Authorization header and all payloads;
6. Tampering persists in the database, remains effective after restart, and the frontend interface shows no anomalies.

AST coverage analysis method and defense strategy

The authors propose a five-step method to quantify the weird machine attack surface: extract AST rewriting logic → enumerate node types handled by the sandbox → compare with ESTree specification node types → classify by exploitation potential (Critical, High, Medium, Low) → calculate coverage score. On the defense side, the authors propose Policy Inversion, which overturns blacklist rewriting into an allowlist that only permits the minimal set of AST nodes required by the workflow, and emphasize that it must be combined with process-level runtime isolation such as V8 isolates or separate containers, as well as credential separation architecture.

Experimental Setup

• System under test and components: The in-depth analysis targets the n8n expression sandbox @n8n/tournament (VariablePolyfill component) and n8n multi-step form nodes (Form.node.ts and utils.ts); architecture comparisons include Apache Airflow (Jinja2), Retool, LangChain.js (expr-eval), and Zapier (AWS Lambda).
• Dataset and specification baseline: ECMAScript ESTree specification (ECMA-262 15th edition, with 72 AST node types total) and Babel AST / ast-types type definitions.
• Auxiliary generation model: An LLM without a specified model name or version (used to automatically generate candidate bypass expressions for unhandled AST nodes).
• Metric definitions: Handled node types, ESTree spec node types, Unhandled node types, AST coverage ratio, CVSS v4.0 score.
• Evaluation and validation methods: Static AST coverage comparison, RCE PoC exploitation validation in local and end-to-end real deployment environments, credential decryption and reverse proxy traffic interception validation.
• Sample size and repetitions: Coverage classification for all 72 ESTree node types; three rounds of vulnerability discovery and patch response tracking against n8n (involving 3 CVEs with CVSS 9.4-9.5); the paper does not report the number of LLM-generated test samples or the number of repeated trials.

Main Results

The main results of the three rounds of vulnerability discovery and escape validation are as follows (per Section 3.2, 3.3, 4.1, and Table A.1):

Swipe horizontally to read the table

CVE ID	Bypass Round	Attack Vector	CVSS Score	Authentication Requirement	Stage of Breakthrough
CVE-2026-25049	Round 1 & 1.5	TaggedTemplate + ODP	9.4	Authenticated	AST rewriting stage
CVE-2026-27577	Round 2	SpreadElement	9.4	Authenticated	Compilation stage
CVE-2026-27493	Round 3	Form node double evaluation	9.5	Unauthenticated	Multi-stage evaluation combination

• Targeted patches are quickly bypassed: The author reports that n8n released PR #23560 within 48 hours after Round 1 to fix template literals, but it was bypassed 4 days later via Object.defineProperty; subsequently, n8n released a comprehensive fix with 9 security hardening measures in v2.4.0, but it was still completely broken by the single-line expression in Round 2.
• Compile-time escapes render runtime defenses completely ineffective: The author notes that the Round 2 SpreadElement vulnerability occurred during the AST rewriting stage; because no normal sandbox wrapper was generated, the 9 runtime checks added in v2.4.0 (PrototypeSanitizer, FunctionThisSanitizer, etc.) were never executed.
• Double evaluation breaks authentication boundaries: The author notes that CVE-2026-27493 is a logical double-evaluation flaw; an attacker without login can exploit the public /form/* endpoint to submit a payload and trigger RCE, with a CVSS score of 9.5.

AST Specification Coverage Quantification and AI-Assisted Enumeration

• What was tested: AST specification coverage measurement of VariablePolyfill in @n8n/tournament, comparing against the 72 node types in the ESTree specification, and using an LLM to generate test cases for unhandled nodes (Section 5.2, Figure 6, Appendix C.5).
• Results: The sandbox handled only 25 node types, a coverage of 35% (25/72), leaving 47 unhandled node types (65%). Among unhandled nodes, 2 were Critical (SpreadElement, RestElement), 4 High (YieldExpression, AwaitExpression, etc.), 10 Medium, and 31 Low. LLM-assisted enumeration directly led to the discovery of CVE-2026-27577.
• Author's interpretation: The author states that 35% coverage indicates the sandbox has 47 potential bypass vectors; using LLM generation and testing of candidate expressions reduced the time to exhaustively test 47 potential vectors from months to hours, eliminating the assumption that traditional enumeration sandboxes rely on the obscurity of gaps.

End-to-End AI Infrastructure Exploitation Chain Validation

• What was tested: Testing the complete attack chain from an external unauthenticated request to persistent interception of LLM API calls in a real n8n deployment environment (Section 4.3, Figure 5).
• Results: After achieving RCE via form endpoint injection, the attacker successfully read process environment variables N8N_ENCRYPTION_KEY; used AES-256-CBC and weak KDF to decrypt the credentials_entity table; tampered with the AI provider's baseUrl to a reverse proxy address and wrote it back to the database. The proxy successfully intercepted API keys and prompt requests, workflows completed normally with all monitoring green, and the attack persisted after restart.
• Author's interpretation: The author states that each node appears normal when examined individually, but the combined pipeline, through trust laundering, grants malicious input credential-level execution privileges; because the intrusion occurs upstream of all checks, downstream monitoring cannot detect it.

Cross-Platform Sandbox Failures and Architectural Isolation Comparison

• What was tested: Surveying other sandbox implementations and failure cases in the orchestration domain (Section 2.3, Section 7.3).
• Results: Jinja2's SandboxedEnvironment was bypassed again by CVE-2025-27516 after the CVE-2024-56326 fix; Retool disclosed a same-process sandbox escape in July 2025; expr-eval exposed CVE-2025-12735; Zapier, despite using Lambda process isolation, suffered the 2022 ZAPESCAPE attack that exploited shared Lambda instances within accounts, which was successfully mitigated after switching to per-user instances.
• Author's interpretation: The author states that this indicates enumeration-blocking sandboxes have structural failures across the entire product category; the Zapier case shows that process-level isolation can work, with the key being the architectural design of the isolation boundary.

Other Ablations and Analyses

• ESTree node coverage: 25 handled, 47 unhandled, 72 total, coverage 35% (Figure 6)
• Severity distribution of unhandled AST nodes: Critical 2, High 4, Medium 10, Low 31 (Appendix C.5)
• Patch response cycle: n8n confirmed reports within 24-48 hours, first patch PR #23560 released within 48 hours (Appendix B)
• v2.4.0 hardening coverage: 9 targeted security fixes released, all at the runtime layer (Section 3.3, Appendix B.1)
• Community independent reproduction scale: more than 4 independent research teams reported more than 6 n8n expression sandbox CVEs within 3 months (Section 7.3)
• Static language checking blind spot: SpreadElement in ast-types is not included in union types like ExpressionKind, TypeScript considers the switch exhaustive, causing unhandled nodes to silently fall into default (Appendix A.3)

Limitations and future directions noted by the authors

• Compositional weird machines with stochastic components (Section 7.3): The authors note that the compositional extension in this paper only covers combinations between deterministic expression engines; a natural future extension is to investigate whether emergent attack surfaces beyond the capabilities of individual components arise when pipelines include stochastic components such as large language models (LLMs) processing natural language.
• Cross-platform analysis and tool validation (Section 7.3): The authors note that the in-depth case study in this paper is n8n, and invite the research community to apply the AST coverage analysis method and tool to other orchestration platforms and publish results.
• Policy inversion cannot replace runtime isolation (Section 6.2): The authors note that policy inversion does not eliminate the need for runtime isolation; an attacker who finds exploitable logic in allowed node type combinations may still escape, so policy inversion must complement runtime process isolation.
• Empirical testing gap for unhandled AST nodes (Section 5.2 and Appendix C.5): The authors note that apart from the confirmed SpreadElement, the remaining 46 unhandled AST nodes have not been individually tested for exploitation; the current severity classification reflects static AST analysis rather than confirmed exploitation.
• Scope limitation of double evaluation elimination (Section 6.2 and Appendix B.2): The authors note that PR #26214 only removed the second evaluation of prepareFormFields in the Form node, but other nodes and components in the platform that may have multi-stage evaluation still require comprehensive audit and elimination.

Experimental coverage

• The tested orchestration systems focus on n8n (@n8n/tournament, nodes-base) as the primary in-depth empirical object, with comparative analysis covering Jinja2 (Airflow), Retool, expr-eval (LangChain.js), and Zapier, totaling 5 platforms (Section 2.3, Section 7.3).
• AST specification coverage metrics are based on 72 node types from the ECMAScript ESTree specification, empirically validating 25 handled nodes and 47 unhandled nodes in @n8n/tournament (Section 5.2, Appendix C.5).
• Vulnerability empirical testing covers three rounds of bypass (CVE-2026-25049, CVE-2026-27577, CVE-2026-27493), and a 6-step end-to-end exploitation chain was validated in a controlled test environment (Section 3, Section 4.3, Appendix A).
• The paper does not report the specific LLM model name, version, prompt structure, or time taken for generated tests when using LLM-assisted enumeration of unhandled nodes (Section 5.4).
• The paper does not report specific measured millisecond values or variance statistics for the latency added by the reverse proxy in the end-to-end attack chain (Section 4.3).

This paper conducts a systematic study of expression sandbox security in AI workflow orchestration systems, revealing the security failure mechanism caused by reliance on enumeration blacklists.

• Core problem and scenario: In mainstream orchestration platforms such as n8n, the user expression evaluation engine, sensitive credential store, and workflow runtime are tightly coupled in the same system process; once an attacker achieves sandbox escape of the expression engine, they can directly obtain decryption keys and fully take over all connected cloud services and AI large model interfaces.
• Theoretical framework and mechanism analysis: The authors model the expression sandbox as a weird machine whose instruction set continuously expands with the language specification; they propose that in multi-stage pipelines, untrusted external input undergoes trust laundering that progressively strips taint marks across nodes, ultimately allowing malicious input to drive credential-protected high-privilege operations without authentication.
• Empirical attacks and exploitation chain validation: In multiple rounds of actual attack testing against n8n, the authors discovered three key vulnerabilities: CVE-2026-25049 (CVSS 9.4) targeting template literals and prototype manipulation, CVE-2026-27577 (CVSS 9.4) using spread syntax to bypass all 9 runtime defenses at compile time, and CVE-2026-27493 (CVSS 9.5) an unauthenticated remote code execution vulnerability via form double evaluation; they also built a transparent reverse proxy to achieve persistent silent hijacking of credentials for calls to large models such as OpenAI.
• Attack surface quantification and automated tool: The authors built an AST coverage quantification analysis method and accompanying open-source tool for the ECMAScript language ESTree specification; measurements show that the n8n expression sandbox covers only 25 of 72 syntax nodes, a coverage of only 35%, with 47 potential bypass vectors, and with LLM-assisted generation, bypass testing of all uncovered nodes can be completed within hours.
• Defense conclusions and architectural insights: The authors point out that enumeration defenses based on AST rewriting and runtime blacklists are structurally unable to withstand language evolution; the defense system must undergo policy inversion (switching to a minimal allowlist that only permits necessary node types), combined with strong process-level runtime isolation represented by V8 isolates or separate containers, and at the architectural level, split credential management and expression computation into different processes.