Notifications
Clear all
Topic starter
09/06/2026 11:19 pm
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.
NHIMG editorial — based on content published by Orca Security: LiquidJS CVE-2026-45618 and the risk of remote code execution in Node.js template rendering
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Review runtime secret exposure around Node.js services Identify which environment variables, mounted files, and API tokens are reachable from each LiquidJS runtime.
What's in the full analysis
Orca Security's full research covers the operational detail this post intentionally leaves for the source:
- Package-level exposure context across workloads and internet-facing assets
- Exploit path details for the valueOf filter chain and JavaScript execution context
- Detection and prioritisation guidance from Orca SideScanning for affected deployments
- Remediation focus on real-risk ranking rather than CVSS alone
👉 Read Orca Security's analysis of LiquidJS remote code execution risk →
LiquidJS remote code execution: what does this mean for Node.js teams?
Explore further
10/06/2026 1:37 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LiquidJS RCE exposes the limits of template trust in Node.js
