AI Threat AlertCVE-2026-77075: n8n: expression injection executes JS in victim session
HIGHn8n's workflow editor takes the stored value of a resource-locator field and splices it directly into a node's URL template without checking for expression syntax, so a value containing n8n's `{{ }}` expression syntax gets evaluated as live JavaScript. Any authenticated member — even a low-privilege one — can plant that payload in a shared workflow, and it fires inside the browser session of the next, potentially higher-privileged, user who simply opens the affected node in the editor. There's no CISA KEV listing, no public exploit, and no Nuclei template yet, and downstream exposure is modest (16 tracked dependents), but n8n itself carries 201 other CVEs and a mediocre 6.6/10 OpenSSF score, and this instance sits squarely in the collaborative, multi-user workflow editor that AI agent teams use daily. Because n8n workflows routinely hold API keys and LLM/agent credentials, cross-user JS execution in the editor is a realistic path to credential theft or silent tampering with agent logic. Patch to n8n 1.123.69, 2.33.4, or 2.34.1 (whichever branch applies) and in the meantime restrict workflow edit access to trusted users and audit shared workflows for resource-locator fields containing `{{` or `}}` that don't belong there.
What is the risk?
Rated high severity with no CVSS vector published. Exploitation requires an authenticated account (member-level, not admin), which lowers the bar in any n8n deployment with shared or self-service signup access, but keeps it out of reach of fully unauthenticated internet scanning. There is no evidence of active exploitation (not in CISA KEV, no SSVC decision published), no public PoC, and no Nuclei template — so near-term opportunistic exploitation risk is low-to-moderate. The real risk driver is n8n's role as a shared, multi-user workflow editor: the victim doesn't need to click a link or run anything unusual, just open a node another member configured, which matches normal collaborative usage patterns and makes accidental triggering likely in team environments.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | — | No patch |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 stepUpgrade immediately to n8n 1.123.69 (1.x line), 2.33.4 (2.x pre-2.34), or 2.34.1 — whichever branch is deployed. Until patched, restrict workflow creation/editing to trusted, vetted users and avoid granting broad 'member' edit rights on shared instances; consider read-only sharing for non-admin collaborators. Detection: audit existing workflows for resource-locator field values containing
{{,}}, or other expression-syntax markers that don't correspond to legitimate dynamic expressions, and review recent workflow edit history for anomalous changes by lower-privileged accounts. Enable/verify audit logging on workflow saves and review editor session activity for unexpected script execution or credential access events following the patch window.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-77075?
n8n's workflow editor takes the stored value of a resource-locator field and splices it directly into a node's URL template without checking for expression syntax, so a value containing n8n's `{{ }}` expression syntax gets evaluated as live JavaScript. Any authenticated member — even a low-privilege one — can plant that payload in a shared workflow, and it fires inside the browser session of the next, potentially higher-privileged, user who simply opens the affected node in the editor. There's no CISA KEV listing, no public exploit, and no Nuclei template yet, and downstream exposure is modest (16 tracked dependents), but n8n itself carries 201 other CVEs and a mediocre 6.6/10 OpenSSF score, and this instance sits squarely in the collaborative, multi-user workflow editor that AI agent teams use daily. Because n8n workflows routinely hold API keys and LLM/agent credentials, cross-user JS execution in the editor is a realistic path to credential theft or silent tampering with agent logic. Patch to n8n 1.123.69, 2.33.4, or 2.34.1 (whichever branch applies) and in the meantime restrict workflow edit access to trusted users and audit shared workflows for resource-locator fields containing `{{` or `}}` that don't belong there.
Is CVE-2026-77075 actively exploited?
No confirmed active exploitation of CVE-2026-77075 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-77075?
Upgrade immediately to n8n 1.123.69 (1.x line), 2.33.4 (2.x pre-2.34), or 2.34.1 — whichever branch is deployed. Until patched, restrict workflow creation/editing to trusted, vetted users and avoid granting broad 'member' edit rights on shared instances; consider read-only sharing for non-admin collaborators. Detection: audit existing workflows for resource-locator field values containing `{{`, `}}`, or other expression-syntax markers that don't correspond to legitimate dynamic expressions, and review recent workflow edit history for anomalous changes by lower-privileged accounts. Enable/verify audit logging on workflow saves and review editor session activity for unexpected script execution or credential access events following the patch window.
What systems are affected by CVE-2026-77075?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration / automation platforms, plugin/integration nodes.
What is the CVSS score for CVE-2026-77075?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012Valid AccountsAML.T0050Command and Scripting InterpreterAML.T0081Modify AI Agent ConfigurationCompliance Controls Affected
What are the technical details?
Original Advisory
n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contain an expression injection vulnerability in resource-locator field link preview rendering. The editor spliced the field's stored value directly into the node type's URL template without checking for expression syntax. An authenticated member can store a malicious value so that when another user opens the affected node in the editor, the injected expression is evaluated as JavaScript in the victim's authenticated session (cross-user script execution).
Exploitation Scenario
An attacker with a standard authenticated 'member' account on a shared n8n instance edits a workflow used by the team, setting a resource-locator field (e.g., a channel picker, table selector, or similar node parameter) to a value containing a crafted `{{ }}` expression that resolves to malicious JavaScript rather than legitimate configuration data. The attacker saves the workflow and waits. When an admin or higher-privileged teammate later opens that node in the editor — a routine action when reviewing or debugging shared AI agent workflows — the stored value is spliced unsanitized into the node's URL template and evaluated as JavaScript in the victim's authenticated browser session. From there the attacker's code can read the victim's session/credentials, silently exfiltrate stored LLM/API keys via n8n's own UI, or modify the workflow's agent logic to redirect tool calls or leak data on future executions — all without the victim clicking anything beyond opening a node they were already trusted to manage.
Weaknesses (CWE)
CWE-94 — Improper Control of Generation of Code: The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
- [Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
- [Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
Source: MITRE CWE corpus.
References
- github.com/n8n-io/n8n/security/advisories/GHSA-fh4c-9rr2-p7qcvendor-advisory
- vulncheck.com/advisories/n8n-before-expression-injection-via-resource-locatorthird-party-advisory
Timeline
Related Vulnerabilities
CVE-2026-3366310.0n8n: member role steals plaintext HTTP credentials
Same package: n8nCVE-2026-3366010.0TensorFlow: type confusion NPD in tensor conversion
Same package: n8nCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same package: n8nCVE-2026-275779.9n8n: Code Injection enables RCE
Same package: n8nCVE-2026-274949.9n8n: security flaw enables exploitation
Same package: n8n