enspirit-elo

Ecosystem: npm

Downloads: 3.02 K

Vulnerabilities from the last (months)
  • 2CriticalAffects 2 versions
  • 1HighAffects 1 version
  • 0MediumAffects 0 versions
  • 0ModerateAffects 0 versions
  • 0LowAffects 0 versions
Severity distribution (all time)
3vulnerabilities
  • Critical2 (66.7%)
  • High1 (33.3%)
  • Medium0 (0.0%)
  • Moderate0 (0.0%)
  • Low0 (0.0%)

Monthly breakdown

  • 3 vulnerabilities
    • Critical: 2
    • High: 1
    • Medium: 0
    • Moderate: 0
    • Low: 0

Vulnerabilities (3)

Known vulnerabilities affecting enspirit-elo, based on data from OSV.

Vulnerabilities affecting enspirit-elo
IDSeveritySummaryAffected versionsPublishedSource
GHSA-33r5-xmm8-v6x5CriticalElo JavaScript emitter has sandbox escape to arbitrary Node.js / browser code execution via unfiltered `.constructor` member access### 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.0.1
GitHub (opens in a new tab)
GHSA-7w38-ggh5-v542CriticalElo Ruby backend has Remote Code Execution via unescaped `#{...}` interpolation in emitted string literals and subtype-constraint labels### 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 al
  • < 1.0.1
GitHub (opens in a new tab)
GHSA-x9rp-7wh3-2rj5HighElo backends have code injection via unvalidated emission of programmatic AST fields### Summary Elo's programmatic AST API accepts arbitrary values in many node fields without runtime type or syntax validation. Each backend's emit stage interpolates those values straight into the generated source with no escape pass. An integrator that populates the AST from JSON-deserialised input, plugin output, or any other untyped source therefore exposes a code-injection primitive that flows through to the emitted JavaScript, Ruby, Python, or SQL. The same pattern was previously addressed in **0.9.7 (2026-01-27)**, which patched the date/datetime/duration literal emitters via `JSON.str
  • < 1.0.1
GitHub (opens in a new tab)
  • GHSA-33r5-xmm8-v6x5Critical
    Elo JavaScript emitter has sandbox escape to arbitrary Node.js / browser code execution via unfiltered `.constructor` member access
    • < 1.0.1

    ### 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`

    CVE: CVE-2026-44267

  • GHSA-7w38-ggh5-v542Critical
    Elo Ruby backend has Remote Code Execution via unescaped `#{...}` interpolation in emitted string literals and subtype-constraint labels
    • < 1.0.1

    ### 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 al

    CVE: CVE-2026-44266

  • GHSA-x9rp-7wh3-2rj5High
    Elo backends have code injection via unvalidated emission of programmatic AST fields
    • < 1.0.1

    ### Summary Elo's programmatic AST API accepts arbitrary values in many node fields without runtime type or syntax validation. Each backend's emit stage interpolates those values straight into the generated source with no escape pass. An integrator that populates the AST from JSON-deserialised input, plugin output, or any other untyped source therefore exposes a code-injection primitive that flows through to the emitted JavaScript, Ruby, Python, or SQL. The same pattern was previously addressed in **0.9.7 (2026-01-27)**, which patched the date/datetime/duration literal emitters via `JSON.str

    CVE: CVE-2026-44265

Showing 1-3 of 3 vulnerabilities