On this page (7 sections)
CVE-2026-44266 is a critical remote code execution flaw in Elo, a purely functional expression language used in no-code tools. When Elo is compiled to Ruby, attacker-controlled text can end up inside Ruby code and be executed, including shell commands. The npm package @enspirit/elo is vulnerable up to and including 1.0.0, and version 1.0.1 fixes it, according to the GitHub advisory.
If you use Elo as a rule engine, configuration language or form builder DSL, or run its command line tool in CI, check your version now. The advisory is currently the only detailed source, so details below come from it and from the CVE record.
What happened
Elo can compile its programs to several targets. According to the advisory, the Ruby emitter writes attacker-controlled text into Ruby double-quoted strings without escaping the # character. In Ruby, # starts an interpolation sequence inside double-quoted strings, and the code inside it is evaluated. That means a crafted Elo string literal or constraint label becomes live Ruby in the generated output.
The advisory was published in the project repository on Oct 30, 2026 and added to the GitHub Advisory Database on Nov 3, 2026. The project's fix commits are public.
Technical details
This is a code injection and output-escaping problem. Untrusted data is treated as code because the generator did not neutralize characters that are special in the target language. The advisory identifies two vulnerable places in src/compilers/ruby.ts:
- The string-literal emitter escapes backslashes, double quotes and control characters, but not #.
- The labelled subtype-constraint branch wraps the error message in a Ruby double-quoted string with no escaping pass at all. The parser accepts single-quoted Elo strings as constraint labels, so a label flows unchanged into the emitted Ruby.
Per the CVE record, a failing labelled subtype constraint evaluates its message, and an ordinary string literal is evaluated when the compiled Ruby runs. Because Ruby allows backticks inside interpolation, this reaches shell command execution. The advisory states that JavaScript, Python and SQL emission are not affected, so the same Elo source can be harmless on one target and dangerous on another.
The advisory rates attack complexity low, with no privileges and no user interaction required. The practical risk depends on whether untrusted people can supply Elo source that you compile to Ruby.
Who is affected
The advisory lists three entry points that share the same root cause:
| Entry point | Who is exposed |
|---|---|
| /try playground on elo-lang.org (Ruby target) | The Elo project's own playground infrastructure |
| bin/eloc -t ruby -x | CI or DevOps hosts that pass Elo strings through the CLI |
| defaultFormats.elo.parse() followed by Ruby emission | Downstream projects using Elo as a rule engine, configuration DSL or form builder DSL |
If you only compile Elo to JavaScript, Python or SQL, this specific path does not apply, though you should still upgrade. Sites that let customers or editors write Elo expressions, for example in a no-code rule builder, deserve the closest look.
How to check your exposure
First find out whether your project depends on @enspirit/elo and which version is installed. This read-only command, run in your project directory, lists the installed version and shows which packages depend on it.
npm ls @enspirit/eloA result of 1.0.0 or lower is vulnerable. Next, search your code and build scripts for Ruby emission, meaning use of the -t ruby option or Ruby output from the library API. This read-only search, run in the repository root, lists files that call the eloc command; any match needs a manual look to see whether the Ruby target is used.
grep -rn "eloc" --include="*.json" --include="*.sh" --include="*.yml" --include="*.yaml" --include="Makefile" .Then ask where the Elo source comes from. If any of it is written by users, imported from outside, or pulled from a shared URL, treat it as untrusted input.
What to do now
Update to the fixed release with npm, then confirm the version. Run both commands in the project root; the second should show 1.0.1 or later.
npm install @enspirit/elo@1.0.1
npm ls @enspirit/elo0 of 6 done
Detection and monitoring
The sources do not describe indicators of compromise beyond the fact that injected code runs with the privileges of the Ruby process. Useful signals are therefore generic: unexpected child processes spawned by Ruby or build jobs, new files in temporary directories, and outbound connections from CI hosts that do not normally make them. Review CI job history for Elo inputs you did not expect.
If you run a public site or app that exposes a rule builder, a free security headers check and our guide on checking whether a website is hacked are reasonable follow-ups, but they cannot tell you whether this library flaw was used against you. For general dependency hygiene, see small business website security.
Status and timeline
- Oct 30, 2026: advisory published in the enspirit/elo repository.
- Nov 3, 2026: published to the GitHub Advisory Database and reviewed; the CVE record shows the same publication date.
- Fixed in @enspirit/elo 1.0.1.
At the time of writing, only the project advisory describes the issue in detail, and the research data shows no reports of exploitation in the wild. The advisory's proof of concept was verified against Ruby 3.x according to the reporter. Treat the lack of reported exploitation as unconfirmed rather than as evidence of safety.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.