What happened
n8n moved the Code node onto a JS task-runner child in a prior GHSA fix, but left the Function/Function Item and LangChain Code nodes running in-process through vm2 NodeVM, only hiding them from the palette. Because the main process lacks the task-runner's sandboxing flags, sample code executed by a member resolves to the n8n main PID and can reach the host: running as the n8n service account, reading encrypted credentials and the database.
Why it matters
n8n is a primary place where teams wire LLM/agent automations (LangChain Code node, credential-fetching nodes). The vulnerable nodes run under the same process that holds all instance credentials and secrets, so a low-privileged workflow author turns into full instance compromise — the exact blast radius that matters for an AI-orchestration deployment.
Attack vector
An authenticated member imports or creates a workflow whose node type is a deprecated Function/Function Item/LangChain Code node and executes it. These nodes are only 'hidden' from the palette (an UI flag, not an ACL) and still run their JavaScript through an abandoned vm2 NodeVM in the n8n main process, which does not get the task-runner hardening flags (--disallow-code-generation-from-strings / --disable-proto=delete).
Affected systems
n8n before 2.42.6, 2.43.x before 2.43.3, and 3.x before 3.0.1. Affected nodes: n8n-nodes-base.function, n8n-nodes-base.functionItem, @n8n/n8n-nodes-langchain.code (CVSS 8.8).
Mitigation
Upgrade to n8n 2.42.6, 2.43.3, or 3.0.1. Do not rely on palette hiding, NODES_EXCLUDE or Workflow Import restrictions; audit instances for saved workflows referencing the deprecated function nodes.