الملخص
### 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 root cause (no denylist in `transform.ts`) and are addressed by the same one-file patch: | # | Entry point | Threat model | |---|---|---| | 1 | Browser playground — `https://elo-lang.org/try/?code=…&run=1` | **0-click XSS / account takeover** against elo-lang.org. `?run=1` triggers `setTimeout(() => this.run(), 100)` in `playground_controller.ts:531`; the server issues a 301 that preserves `?code=`. Any shared URL that contains a payload compromises the visitor's session on elo-lang.org. | | 2 | `bin/el…