Tag: critical

• Severity: CRITICAL
• CVE: CVE-2026-44267
• Ecosystems: npm
• Packages: @enspirit/elo

### Summary

An unauthenticated attacker who controls a string passed to any Elo JavaScript-emission path — `defaultFormats.elo.parse()`, the `bin/elo` CLI, or the live browser playground at `elo-lang.org/try` — can execute arbitrary code in the host JavaScript runtime. A payload built from the `.constructor.constructor` chain compiles, without modification, to a live `Function` invocation in the emitted JavaScript, escaping any sandbox assumption around “Elo is a safe data/DSL language.”

### Vulnerable sink and root cause

Three interacting sites in `src/` produce the bug at commit `749af7b`:

1. **`src/transform.ts:144–158`** — the `member_access` handler allows access on types `any`, `object`, or `array` without filtering the property name. This is the only place an integrator could have plugged a denylist.
2. **`src/compilers/javascript.ts:210`** — the JS emitter writes `${objectExpr}.${ir.property}` verbatim into the output, so any property name that survives the transform step flows unescaped into emitted JavaScript.
3. **`src/parser.ts:163–170, 748–750`** — the parser accepts `constructor` (and other JS meta-property names) as an ordinary identifier, so `.constructor` clears type-checking without triggering any warning.

Combined, the Elo expression `({}).constructor.constructor(‘…’)()` compiles to a live `Function(‘…’)()` call in the emitted JS, executing in the realm of whichever sink runs the compiled code.

### Attack surfaces

All three surfaces share the same ro…

Source: GitHub Security Advisories · 2026-11-03

• 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