CVE-2026-44265 enspirit CVE debrief

Who should care

Defenders of systems using Elo backends, especially those with untrusted input or plugin output, should assess exposure and prioritize verification and remediation. This includes reviewing the version of @enspirit/elo and upgrading to 1.0.1 or later if necessary. Additionally, defenders should implement input validation and sanitization for AST fields, review compensating controls for exposed systems, and monitor for potential exploitation.

Why it matters

The vulnerability allows for code injection in Elo backends, posing a risk to systems using these backends with untrusted input or plugin output. Defenders should prioritize verification and remediation.

• Code injection can lead to arbitrary code execution
• Injection can occur in emitted JavaScript, Ruby, Python, or SQL
• Defenders must verify exposure in systems using Elo backends

Technical summary

The vulnerability is caused by the lack of runtime type or syntax validation in Elo's programmatic AST API. This allows an attacker to inject arbitrary code into the emitted JavaScript, Ruby, Python, or SQL. The API accepts arbitrary values in many node fields without proper validation, and the emitted code is generated by interpolating these values without any escape pass. As a result, an integrator that populates the AST from JSON-deserialised input, plugin output, or any other untyped source exposes a code-injection primitive. The vulnerability affects multiple backends, including those emitting JavaScript, Ruby, Python, and SQL.

Defensive priority

Defenders should prioritize verifying exposure in systems using Elo backends, especially those with untrusted input or plugin output. They should assess the version of @enspirit/elo and upgrade to 1.0.1 or later if necessary.

Recommended defensive actions

• Verify the version of @enspirit/elo and upgrade to 1.0.1 or later if necessary
• Assess exposure in systems using Elo backends with untrusted input or plugin output
• Implement input validation and sanitization for AST fields
• Review compensating controls for exposed systems while remediation is scheduled and verified
• Check relevant monitoring, detection, and logs for exposed assets that need extra review
• Track exceptions, retest remediated assets, and close the item only after evidence is documented
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up

Evidence notes

The source item from osv_dev provides details about the vulnerability, including the affected AST fields and backends. However, the corpus does not establish specific exploitation or impact, requiring verification from official sources.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.