n8n CVE-2026-119408

Requires an authenticated n8n account with permission to create, modify, or import workflows (PR:L), plus the ability to add one of three specific deprecated/hidden node types: the Function node, the Function Item node, or the LangChain Code node (n8n-nodes-base.function, n8n-nodes-base.functionItem, @n8n/n8n-nodes-langchain.code). On vulnerable releases these nodes execute user code in the n8n main process rather than the isolated task runner. What limits exploitation: the attacker must already be authenticated with workflow-authoring rights, and the affected node types are deprecated and hidden. On patched versions (2.42.6, 2.43.3, 2.44.0, 3.0.1) saving or importing a workflow that adds or changes these nodes is rejected by default, so exploitation additionally requires that an operator has set N8N_DEPRECATED_NODES_BLOCK=false (which restores the vulnerable behavior) or is still running a pre-fix version; note that already-saved workflows containing these nodes continue to run unchanged even after patching.

This is a genuine, high-priority issue but not an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) correctly captures that exploitation is network-reachable, low-complexity, and requires only low-privilege authentication (PR:L) - specifically an account that can create, modify, or import workflows. Impact is severe (VC:H/VI:H/VA:H) because code runs in the n8n main process, outside the task runner isolation that normally contains Code node execution, so a successful attacker gains full read/write/availability control of the n8n host. The vuln.today Decision label is this_week, consistent with a serious authenticated RCE that is not yet mass-exploited. No EPSS score and no KEV listing were provided, so there is no signal of widespread or confirmed active exploitation; absence of these is not itself evidence of safety. A public research write-up (abraxaslabs.tech, 'n8n-function-vm2') and a VulnCheck advisory are referenced, but the input does not mark any of them as confirmed working exploit code, so this should be treated as a public PoC reference rather than a verified exploit. The practical risk gate is the PR:L requirement: in deployments where many users (or SSO-federated/low-trust users) can author workflows, this is effectively a privilege-escalation-to-host primitive; in single-trusted-operator deployments the real-world risk is lower.

An authenticated n8n user who has permission to create or edit workflows adds a deprecated Function, Function Item, or LangChain Code node and places attacker-controlled JavaScript in it. When the workflow runs, that code executes in the n8n main process rather than the isolated task runner, giving the attacker arbitrary code execution on the n8n server. A public PoC reference exists (abraxaslabs.tech research and the VulnCheck advisory); it is not verified as working exploit code in the supplied data.