Elo EUVD-2026-116108

Exploitation requires an integrator to use Elo's programmatic AST API and populate specific node fields - int_literal/float_literal .value, variable.name, member_access.property, object_literal keys, datapath segments, lambda.params[].name, or the SQL let-binding name - from untrusted or untyped sources (JSON-deserialized input, plugin output) and then compile to a backend, because the emit stage interpolates those values with no runtime syntax validation. JS/Ruby/Python targets yield arbitrary code execution; the SQL target yields SQL injection (undefined identifiers are intentionally emitted as column references). LIMITING FACTORS: this is not exploitable when the AST is built only from trusted or parser-produced input, the data flow is a non-default integration choice (hence AC:H), and this programmatic-AST path is distinct from the plain-string constructor-chain sandbox escape (GHSA #2). The only complete fix per the advisory is updating to 1.0.1, which adds validation at every backend emit site.

The source-supplied CVSS 3.1 vector (AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, base 7.4) encodes the central tension: the impact is maximal (full C/I/A compromise via arbitrary code execution in JS/Ruby/Python targets and SQL injection in the SQL target), but exploitation is gated (AC:H) and not inherently network-exposed (AV:L) because the flaw lives in a library's programmatic AST API rather than a network listener. PR:N correctly reflects that the API performs no authentication of its own. No EPSS score and no CISA KEV entry are present in the input, so there is no signal of widespread or active exploitation; exploitation status rests on a public PoC reference in the GHSA advisory, not on observed attacks. The vuln.today decision label is 'this_week' (priority but not emergency/act_now), which is consistent with high technical impact plus an obscure, niche product and no exploitation evidence. The realistic risk is conditional, not universal: it is a genuine code-execution bug, but only for integrators who pipe untrusted/untyped data into the programmatic AST without validation - so it is a real priority for those specific deployments and lower real-world risk for consumers who only build ASTs from trusted/parsed Elo source. Note the AV:L vs. the description's 'JSON-deserialized input' mismatch: in many integrations the tainted data arrives remotely, so effective reachability can be higher than AV:L implies - verify against the actual integration.

An integrator builds a no-code tool that deserializes attacker-supplied JSON into Elo's programmatic AST and compiles it to a backend. The attacker supplies a crafted int_literal value such as "(console.log('PWN'),1)" for JavaScript, "(system('touch /tmp/pwn'); 1)" for Ruby, or a variable.name like "1; DROP TABLE users; --" for SQL, which the emit stage interpolates verbatim into the generated source, yielding arbitrary code execution or SQL injection. The GHSA advisory embeds PoC snippets and references attached ast-exec.js/ast-exec2.js scripts that the reporter verified end-to-end at commit 749af7b, though exploitation still requires the AC:H precondition of an unsafe untrusted-to-AST data flow.