Elo DSL "Sandbox" Breaks: Unfiltered `.constructor` Access Yields Arbitrary Code Execution in Node.js and Browser

A newly disclosed GitHub Security Advisory (GHSA-33r5-xmm8-v6x5, CVE-2026-44267, CVSS 9.8) reports that the @enspirit/elo JavaScript DSL compiler fails to filter the .constructor property during member-access handling. According to the advisory, an attacker-controlled Elo string such as ({}).constructor.constructor('...')() compiles unmodified into a live Function(...)() call in the emitted JavaScript — breaking the language's core safety assumption that Elo is a sandboxed data/DSL language rather than an arbitrary-code-execution vector. A public proof-of-concept is available.

The advisory identifies three affected entry points that all share this single root cause: the defaultFormats.elo.parse() library API (Node.js RCE for any application embedding Elo as a rule engine or config DSL), the bin/elo CLI (RCE on CI/DevOps hosts, including via a data-only flag that integrators would not expect to execute code), and the live browser playground at elo-lang.org/try (reported as a zero-click XSS/account-takeover path via a URL parameter that survives a server redirect).

Why it matters for defenders

Elo is documented as a rule-engine and configuration/form-builder DSL, meaning the realistic blast radius is any backend, CI pipeline, or internal tool that parses untrusted or semi-trusted Elo input and assumes it cannot reach the host JS runtime. Because the advisory describes this as unauthenticated and requiring only a plain string (no attacker-controlled AST object), the barrier to exploitation is reported as low wherever Elo strings originate from user input, uploaded config, or form submissions.

What to watch for / do now

• Inventory any service, CLI tooling, or CI job that calls elo (library, bin/elo, or embeds the playground) and treat Elo input as untrusted if it ever originates outside your own code.
• Check for and apply an upstream patch/version bump to @enspirit/elo once available; the advisory notes the fix is a single-file change to the member-access filtering in transform.ts.
• Until patched, avoid parsing user-supplied Elo strings server-side or in CI; if parsing cannot be avoided, consider running it in an isolated process/sandbox rather than the host runtime.
• Hunt for suspicious child-process spawns (e.g., execSync, shell invocations) immediately following Node processes that load elo, and review logs for Elo payloads containing constructor.constructor patterns.
• For any internet-facing use of the playground pattern, review for URL parameters that pass code into an auto-execute path, and treat shared links containing such parameters as potentially malicious.

This is a fresh, same-day disclosure and still developing — details on vendor patch timelines and downstream exposure may evolve. See the original advisory for full technical details and proof-of-concept: GHSA-33r5-xmm8-v6x5.