- Severity: CRITICAL
- CVE: CVE-2026-44266
- Ecosystems: npm
- Packages: @enspirit/elo
### Summary
Elo’s Ruby backend emits attacker-controlled text into Ruby double-quoted strings without escaping the `#` character. Because `#` begins Ruby’s interpolation sequences — `#{expr}`, `#@ivar`, `#@@cvar`, `#$gvar` — and any expression wrapped in `#{…}` may use backticks for shell execution, an Elo program that contains a crafted string literal or a labelled subtype constraint compiles to Ruby that evaluates attacker-chosen Ruby, and through backticks runs attacker-chosen shell commands, at runtime.
The same Elo source compiled to JavaScript, Python, or SQL is benign, so the bug also breaks the cross-target portability guarantee the rest of the compiler honours.
### Vulnerable sinks
Two sinks exist in `src/compilers/ruby.ts` at commit `749af7b`:
1. **String-literal emitter — lines 180–184.**
The emitter escapes backslash, double quote, and control characters, but not `#`. Any `#{…}` sequence in an Elo string literal flows straight into the emitted Ruby source.
2. **Labelled subtype-constraint branch — lines 405–412.**
The error message passed to `p_fail(p, “…”)` is wrapped in a Ruby double-quoted string with no escape pass at all. Because the parser at `src/parser.ts:1339–1348` accepts single-quoted Elo strings as constraint labels, a label such as `’#{` “ `id` “ `}’` flows unchanged into the emitted Ruby.
### Attack surfaces
All three surfaces share the same root cause (the missing `#` escape in the Ruby double-quoted-string emission path) and are a…
Source: GitHub Security Advisories · 2026-11-03