LiquidJS RCE exposes the limits of template trust in Node.js

At a glance

What this is: LiquidJS CVE-2026-45618 is a critical Node.js template injection flaw that can escalate to full remote code execution from crafted input.

Why it matters: For IAM, NHI, and platform teams, it shows how untrusted template processing can become a credential, host, and lateral-movement risk even when no authentication is involved.

👉 Read Orca Security's analysis of LiquidJS remote code execution risk

Context

LiquidJS is a server-side template engine for Node.js, and this vulnerability shows what happens when attacker-controlled template content reaches the rendering engine. In practice, that turns a presentation-layer component into a code-execution path, which is why dependency governance now matters for application identity and runtime trust.

The identity security angle is broader than application patching. Once a service can be driven from template input to JavaScript execution, the resulting compromise can expose secrets, service credentials, and internal data flows that NHI programmes are supposed to protect.

Key questions

Q: What breaks when LiquidJS template input is not trusted?

A: The rendering engine can become a code-execution path instead of a text-processing layer. In CVE-2026-45618, crafted template input can reach internal JavaScript execution contexts and lead to arbitrary command execution, file reads, and host compromise. The practical failure is that the template boundary no longer protects the runtime.

Q: Why do Node.js template engines create secret-exposure risk?

A: Node.js services often hold API keys, tokens, and backend credentials in the same process that renders templates. When a template engine can be driven into arbitrary execution, those secrets become reachable from the compromised runtime. That makes template injection a non-human identity and host trust problem, not just an application bug.

Q: How do security teams know if LiquidJS exposure is actually dangerous?

A: Exposure is most dangerous when the affected service processes attacker-controlled templates, is internet-facing, and can read secrets or invoke child processes. If the vulnerable package is only present in a dormant component, risk is lower. The real signal is reachable execution plus reachable credentials, not package presence alone.

Q: Who is accountable when a template engine flaw leads to host compromise?

A: Application owners, platform teams, and vulnerability management all share accountability because the flaw spans code, runtime, and dependency governance. The response obligation is to remove exploitable exposure, verify dependency versions, and confirm that no sensitive secrets remain reachable from the affected process.

Technical breakdown

How crafted Liquid template input reaches JavaScript execution

LiquidJS evaluates template expressions through filter logic. In CVE-2026-45618, malformed input can break out of the intended rendering path and expose internal JavaScript execution context. From there, the attacker can influence parser and loader references, then reach the Function constructor, which is one of the standard ways arbitrary code execution becomes possible in Node.js. The key issue is not just unsafe input, but the ability of template evaluation to cross from data handling into executable runtime objects.

Practical implication: treat any attacker-controlled Liquid template as a potential code-execution vector until the vulnerable version is removed.

Why changed scope makes the exposure wider than the package itself

The disclosed CVSS vector indicates changed scope, which means compromise is not limited to the vulnerable library. Once arbitrary command execution is available, the attacker can read local files, extract credentials, and move from the application process into adjacent infrastructure. That is especially dangerous in Node.js services that hold API keys, cloud tokens, or backend secrets in environment variables or filesystem mounts. The package becomes the entry point, but the real blast radius is the host and whatever the host can reach.

Practical implication: map which secrets, tokens, and internal services are reachable from any process that loads LiquidJS.

Why public proof-of-concept code changes the operational risk

A public proof of concept reduces attacker work from research to execution. That matters because internet-facing web apps, CMS tools, and email templating systems often accept content from users or downstream systems without strong trust boundaries. When a template engine can be triggered remotely and reliably, exploitation often shifts from opportunistic to automated scanning. The question is no longer whether the flaw is real. It is how quickly exposed services are found, exploited, and used to harvest secrets or pivot further.

Practical implication: prioritize emergency exposure checks for any service processing untrusted templates over routine patch queues.

Threat narrative

Attacker objective: The attacker aims to gain arbitrary command execution on the host, then use that foothold to steal secrets, disrupt services, and expand into connected systems.

1. Entry occurs when an attacker submits crafted Liquid template input to a service that renders untrusted content with a vulnerable LiquidJS version.
2. Credential or code access follows when the input escapes filter evaluation and reaches internal execution context, letting the attacker invoke the JavaScript Function constructor and run commands.
3. Impact occurs when arbitrary command execution is used to read files such as /etc/passwd, harvest secrets, and compromise the host or adjacent infrastructure.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Template evaluation is now a code-execution boundary, not a harmless rendering step. LiquidJS shows how quickly a templating engine can become a host compromise path when internal execution contexts are reachable from attacker-controlled input. That is an application-layer governance failure with identity consequences, because secrets, tokens, and runtime permissions often sit inside the same process. Practitioners should treat template rendering as a privileged execution surface, not a text-processing utility.

Changed scope is the real warning sign here. The flaw does not stop at the vulnerable package, because arbitrary command execution creates a path into whatever the host can access. This is where NHI governance and application security intersect: API keys, cloud credentials, and service tokens are frequently exposed in the runtime that templates can now reach. The implication is that dependency risk must be assessed by reachable secrets and trust boundaries, not by package version alone.

Public exploit code collapses the time available for manual response. Once a proof of concept exists, internet-facing Node.js applications become a scanning target, and exposure can move from disclosure to active exploitation very quickly. That makes inventory, reachability, and runtime context more important than static vulnerability counts. Practitioners should assume that any untrusted-template path with LiquidJS becomes a high-probability compromise candidate.

Secret visibility becomes the deciding control, not just patch speed. Even after remediation, the business impact depends on whether services were able to read local credentials, backend tokens, or configuration secrets before containment. That is why identity teams need to understand which workloads can reach which secrets, and which applications are allowed to render user-controlled templates. The practical conclusion is that runtime trust and secret exposure analysis have to be joined together.

LiquidJS defines a named concept: template-to-execution collapse. This is the failure mode where a rendering component crosses into code execution because internal interpreter objects are reachable from crafted input. It is not just injection in the abstract. It is a specific collapse of the boundary between content rendering and privileged runtime access, and it should change how teams classify template engines in their risk models.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly hidden machine access can outgrow policy coverage.
• For a deeper breach lens, 52 NHI Breaches Analysis shows how exposed credentials and over-privilege turn runtime compromise into broader identity failure.

What this signals

Template-to-execution collapse: once a renderer can reach internal interpreter state, the security model has already failed at the boundary between content and code. For teams running Node.js services, that means dependency inventories have to be paired with runtime reachability and secret access maps, not treated as separate exercises.

The governance lesson is that exposure is only half the story. When service accounts, API keys, or cloud tokens sit behind the same host that processes untrusted templates, the compromise path becomes an identity problem as much as an application flaw.

Orca Security's finding reinforces a wider pattern: high-volume dependencies can create hidden privilege surfaces that traditional patch dashboards understate. Teams should link vulnerability management to asset criticality and secret proximity, especially in internet-facing templating workflows.

For practitioners

• Patch LiquidJS to 10.26.0 or later immediately Upgrade every application and transitive dependency that embeds LiquidJS, then verify the running package version in each deployable artifact. Do not wait for a maintenance window if the service is internet-facing or processes untrusted template content.
• Block untrusted template input until remediation is complete Remove any workflow that allows external users, CMS content, or downstream systems to submit Liquid templates into production rendering paths. If that is not possible, isolate the renderer so it cannot access secrets, system utilities, or internal control planes.
• Review runtime secret exposure around Node.js services Identify which environment variables, mounted files, and API tokens are reachable from each LiquidJS runtime. Prioritise any service that can invoke child processes, load cloud credentials, or read shared configuration from disk.
• Scan for transitive LiquidJS dependency use Check web apps, CMS platforms, email templating systems, and build pipelines for indirect package inclusion. Many teams will miss the vulnerable library if they only review direct dependencies.
• Validate internet-facing exposure before triage ends Map which deployments accept externally supplied templates and which are reachable from the public internet. Use that exposure view to set remediation order, because reachable services are the most likely initial targets.

Key takeaways

• LiquidJS CVE-2026-45618 turns crafted template input into a path to arbitrary code execution, which makes template rendering a privileged trust boundary.
• The practical blast radius includes host compromise, file reads, and secret exposure, especially where Node.js services process untrusted content at internet-facing edges.
• Patching matters, but teams also need exposure mapping, dependency tracing, and secret reachability review to limit the impact of similar template-engine flaws.

Key terms

• Template-to-execution collapse: A failure mode where a rendering engine crosses from processing text into executing code because attacker-controlled input can reach internal interpreter objects. In practice, the boundary between content and runtime disappears, so a templating flaw becomes a host compromise path rather than a simple validation bug.
• 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.
• Secret reachability: The degree to which a runtime can access credentials, tokens, certificates, or configuration files at execution time. Secret reachability is a practical risk measure because a code-execution flaw is far more damaging when the compromised process can immediately read and reuse sensitive identity material.
• Untrusted template rendering: Any workflow in which user-controlled or externally sourced template content is processed by a server-side engine. This pattern is high risk when the renderer has access to commands, files, or secrets, because template syntax can become a vehicle for crossing from data into execution.

Deepen your knowledge

Template engine risk, runtime trust boundaries, and secret exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is responsible for Node.js services or secret-bearing workloads, it is worth exploring.

This post draws on content published by Orca Security: LiquidJS CVE-2026-45618 and the risk of remote code execution in Node.js template rendering. Read the original.