Skip to content

← Public intelligence

npm package

@enspirit/elo

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Critical, CVSS 9.8npmAmendedPublished

    Elo JavaScript emitter has sandbox escape to arbitrary Node.js / browser code execution via unfiltered .constructor member access

    CVE-2026-44267 · GHSA-33r5-xmm8-v6x5

    Affected
    • npm @enspirit/elo < 1.0.1
    Fixed in
    1.0.1· Vendor fix available
    Issue
    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…

    Recommended action: Upgrade to 1.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  2. Critical, CVSS 9.8npmAmendedPublished

    Elo Ruby backend has Remote Code Execution via unescaped #{...} interpolation in emitted string literals and subtype-constraint labels

    CVE-2026-44266 · GHSA-7w38-ggh5-v542

    Affected
    • npm @enspirit/elo < 1.0.1
    Fixed in
    1.0.1· Vendor fix available
    Issue
    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.…

    Recommended action: Upgrade to 1.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  3. High, CVSS 7.4npmAmendedPublished

    Elo backends have code injection via unvalidated emission of programmatic AST fields

    CVE-2026-44265 · GHSA-x9rp-7wh3-2rj5

    Affected
    • npm @enspirit/elo < 1.0.1
    Fixed in
    1.0.1· Vendor fix available
    Issue
    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.stringify()` after a report by naoyashiga. This advisory generalises that fix to the remaining AST surface — at least 23 emission sites across six node-field categories and four backends. Vulnerable sinks Each row is a category of sinks that share the same shape: TypeScript signature erased at runtime → AST-API consumer passes a crafted value → emit interpolates the value verbatim. | | AST…

    Recommended action: Upgrade to 1.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →