TL;DR: LiquidJS CVE-2026-45618 lets attackers reach arbitrary JavaScript execution through crafted template input, with public exploit code already demonstrating file reads and command execution, according to Orca Security. The issue turns template rendering into a host-compromise path, so dependency exposure and untrusted content handling now matter as much as patching.
At a glance
What this is: This is an analysis of a critical LiquidJS vulnerability that turns crafted template input into arbitrary JavaScript execution in Node.js environments.
Why it matters: It matters because teams that let untrusted content reach template engines may be exposing application workloads, files, and credentials to full host compromise.
By the numbers:
- LiquidJS had over 7.3 million monthly npm downloads when CVE-2026-45618 was disclosed.
- CVE-2026-45618 was assigned CVSS 10.0.
Context
LiquidJS is a server-side template engine used in Node.js applications, CMS platforms, email templating systems, and other services that render Liquid content. The security problem is not template syntax itself, but the assumption that template input stays safely inside a rendering boundary once the engine evaluates it.
CVE-2026-45618 breaks that assumption by allowing crafted template expressions to reach internal JavaScript execution paths during rendering. In identity and access terms, this matters because application runtimes, automation services, and downstream systems often inherit trust from whatever processes feed the template engine.
The article describes a case where untrusted content becomes an execution path without authentication or user interaction. That is not a narrow parsing bug, but a host-level trust failure in applications that process attacker-influenced templates.
Key questions
Q: What should teams do first when a template engine can execute attacker-controlled input?
A: The first move is to remove untrusted template paths and patch the vulnerable engine everywhere it runs. If external content can still reach the renderer, a fixed version alone will not close the exposure. Teams should inventory every service that renders templates, then confirm that user input is treated as data only, not executable syntax.
Q: Why do template-engine flaws create host compromise risk instead of staying inside the app?
A: Because once rendering reaches internal execution contexts, the attacker is no longer limited to formatting output. They can often read files, access secrets, and invoke system commands from the application runtime. The scope of impact depends on what the process can reach, not just on the library version.
Q: What are the signs that a Node.js template service is exposed to dangerous input paths?
A: Look for services that render partner content, CMS fields, notification templates, or user-supplied expressions without strict separation between data and template syntax. If the same code path also has filesystem or secrets access, the blast radius is already too large for safe experimentation.
Q: How should security teams contain the impact of template execution bugs in production?
A: Place rendering workloads in tightly scoped runtime environments with minimal file, network, and secret access. If compromise occurs, the attacker should not be able to pivot from template execution into credentials, internal services, or privileged operating-system actions.
Technical breakdown
How LiquidJS filter evaluation becomes code execution
LiquidJS evaluates filters while rendering templates, which means attacker-controlled input can influence the interpreter’s runtime state if input handling is weak. In CVE-2026-45618, the problem begins when a crafted expression such as 1|valueOf reaches internal execution context objects. Once an attacker can reference parser, loader, and filter objects, the rendering engine stops acting like a safe formatter and starts exposing JavaScript internals. The final step is access to the Function constructor, which turns template evaluation into arbitrary command execution on the host.
Practical implication: Treat template rendering as code execution boundary and remove untrusted template paths from production workflows.
Why unauthenticated template input is dangerous in Node.js services
Node.js services often embed templating in CMS workflows, email generation, notifications, and API-driven content rendering. If any of those paths accept user-controlled or partner-controlled template fragments, the template engine becomes part of the attack surface rather than a presentation layer. The vulnerability is especially dangerous because no authentication or user interaction is needed, so internet-facing services can be reached directly. In practical terms, the same dependency can create risk across application tiers, not just in the component that imports it directly.
Practical implication: Inventory every service that renders Liquid templates and classify which ones accept external content.
Changed scope means the blast radius extends beyond the package
The article notes that the CVSS vector reflects changed scope, which means compromise does not stay confined to the vulnerable package. Once arbitrary code executes, the attacker can read files such as /etc/passwd, access credentials, and run operating-system commands through child_process.execSync or similar primitives. That shifts the security question from library patching to environment trust: what the vulnerable process can reach, mount, read, or call determines the real impact. In a shared runtime, one templating flaw can become a broader infrastructure incident.
Practical implication: Map template-engine reachability to filesystem, secrets, and network access before patching windows close.
NHI Mgmt Group analysis
Template engines are execution surfaces, not safe text processors: CVE-2026-45618 shows that template trust assumptions fail when rendering logic can reach runtime objects and constructors. The issue is not just about a vulnerable package, but about allowing untrusted input to cross from content handling into interpreter state. Practitioners should treat template rendering as an execution boundary that deserves the same scrutiny as deserialisation and command invocation.
Dependency exposure now matters as much as direct use: the article makes clear that transitive consumers of LiquidJS can inherit the risk even when the package is not their primary design choice. That means inventory blind spots in CMS platforms, email systems, and Node.js services can create hidden host-compromise paths. The practical implication is that software composition data must be tied to runtime reachability, not left as a static bill of materials.
Changed scope is the real security signal in this class of bug: once a template engine can escape into host execution, the vulnerable component is only the doorway. File access, command execution, and credential theft become environment questions, not just library questions. The implication is that runtime privilege, mounted secrets, and outbound connectivity define the blast radius more than the CVE label does.
Untrusted template input is a governance problem, not just a patching problem: many teams still assume only trusted developers can author templates, while the article shows the danger appears when user-controlled content reaches the renderer. That assumption fails wherever business workflows let external data influence template syntax. The practitioner conclusion is to separate data from executable template logic and reclassify template ingestion paths as security-relevant interfaces.
Template trust debt: organisations accumulate risk when rendering components are reused across services without a clear boundary for who may influence template syntax and when. That debt becomes visible only when a single expression can recover parser objects, loader references, and execution primitives. Teams should re-evaluate which application paths are allowed to compose templates dynamically.
What this signals
The operational lesson is straightforward: template engines must be governed like code execution surfaces, because one unsafe expression can expose the runtime, not just the page or message being rendered.
Template trust debt: security teams should track where user-controlled content can influence syntax, because the highest-risk paths are often hidden in CMS integrations, notification systems, and transitive dependencies.
For practitioners
- Patch to LiquidJS 10.26.0 or later Upgrade every direct and transitive deployment of liquidjs to version 10.26.0 or later, then verify that build artifacts, containers, and serverless packages no longer ship the vulnerable release.
- Restrict attacker-controlled template input Block user-controlled or partner-controlled template fragments from reaching LiquidJS until the update is deployed, and separate content fields from executable template syntax in application flows.
- Map runtime reachability for template services Identify which Node.js services render Liquid templates and record whether they can reach secrets, local files, internal APIs, or command execution primitives.
- Reduce host blast radius for rendering processes Run template-rendering workloads with the minimum filesystem, network, and secret access needed so a template escape cannot immediately expose the wider environment.
Key takeaways
- LiquidJS CVE-2026-45618 turns crafted template input into arbitrary JavaScript execution, which means the application boundary is weaker than many teams assume.
- The article shows a path from input handling to internal engine objects, Function constructor access, file reads, and command execution, so the risk is host compromise rather than output corruption.
- Immediate patching matters, but governance over who can influence template syntax and what the rendering process can reach is what limits the blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unsafe template handling and exposed rendering paths create a misconfiguration-style attack surface in Node.js services. |
| Recommendation — Harden template rendering paths and remove unsafe exposure of untrusted input to the execution layer. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The vulnerability reflects a secure-design failure where input reaches execution primitives. |
| Recommendation — Review application architecture so untrusted content cannot reach code execution primitives during rendering. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The exploit can expose credentials and create paths for movement beyond the initial Node.js service. |
| Recommendation — Map template-execution exposures to credential access and lateral movement risks in your detection and response plans. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article notes credential exposure and host compromise, both of which depend on privileged account reach. |
| Recommendation — Limit account reach in rendering environments so compromised templates cannot inherit broad operating privileges. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The exploit originates in improper handling of crafted template input. |
| Recommendation — Apply SI-10 to validate and constrain template input before it reaches the renderer. | ||
Key terms
- Template Injection: Template injection happens when attacker-controlled input is interpreted as part of a server-side template rather than plain data. If that input reaches rendering logic unsafely, it can expose data, manipulate output, or lead to code execution depending on the templating engine and surrounding controls.
- Changed scope: A vulnerability property that means compromise is not contained inside the affected component. Once the flaw allows code execution or privilege abuse, the attacker can affect the host, secrets, and downstream systems that the component can reach, which makes the blast radius much larger than the package itself.
- Execution boundary: The point at which an authorised task turns into a real system change, such as writing data, deleting records, spending money, or invoking a downstream tool. In AI governance, controlling the execution boundary matters more than simply approving access, because harm occurs when actions are allowed to complete unchecked.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org