Elo Compiler's Ruby Target Allows RCE via Unescaped `#{}` Interpolation (CVE-2026-44266, CVSS 9.8)

What happened

A security advisory (GHSA-7w38-ggh5-v542, tracked as CVE-2026-44266) discloses that the Ruby backend of the Elo compiler (@enspirit/elo on npm) fails to escape the # character when emitting attacker-controlled text into Ruby double-quoted string literals. The # character begins Ruby interpolation sequences such as #{expr}. As a result, a crafted Elo string literal or a single-quoted subtype-constraint label can inject a Ruby expression, including backtick shell execution, into the generated Ruby source. The reporter identifies two vulnerable sinks in src/compilers/ruby.ts: the string-literal emitter and an unescaped error-message branch for subtype constraints. The report provides working proof-of-concept Elo source that, once compiled and run on Ruby 3.x, executes arbitrary shell commands. The advisory notes that the same source compiled to JavaScript, Python, or SQL does not trigger this behavior, so the flaw is isolated to the Ruby emission path. A public PoC is available and CVSS is rated 9.8 (critical).

Why it matters for defenders

Elo is positioned as a rule engine, configuration DSL, and form-builder DSL. Untrusted or semi-trusted input such as rules, config, and form definitions is a documented use case, not an edge case. The advisory lists three concrete exposure paths. The first is the public /try playground on elo-lang.org, which allows zero-click RCE against that infrastructure from a shared URL. The second is the bin/eloc -t ruby -x CLI, which allows RCE on any host, including CI/DevOps pipelines, that compiles and executes Elo source with the Ruby target. The third is any downstream application embedding the library's defaultFormats.elo.parse() with a Ruby emission step. Anyone who lets end users or external data author Elo source that is later compiled to Ruby is directly exposed to full shell-level compromise of the executing process.

What defenders should watch for or do now

• Inventory whether your organization depends on @enspirit/elo and whether any code path compiles Elo source to Ruby and executes it (eloc -t ruby -x, or a library call that parses and runs Ruby output).
• Treat any Elo source that originates from users, config files, form submissions, or other external input as untrusted if it reaches the Ruby target. Until patched, avoid executing Ruby-emitted output derived from such input.
• Hunt for anomalous child processes spawned from Ruby interpreters invoked via eloc or related tooling, or unexpected file-system side effects such as unexplained file creation correlating with Elo compilation jobs in CI logs.
• Review CI/CD pipelines and internal services for use of the Elo CLI or library against untrusted input, and restrict or sandbox such execution until a fix is confirmed upstream.
• Watch the advisory for a patched release and prioritize upgrading @enspirit/elo once available, given the public PoC and critical severity.

Developing situation

This is fresh, same-day intel based on a public GHSA advisory. Patch availability and real-world exploitation status were not confirmed at the time of writing. Full technical details and the original PoC are available in the GitHub Security Advisory GHSA-7w38-ggh5-v542.