n8n EUVD-2026-56143

Exploitation requires all of the following concurrent conditions: (1) the n8n instance must be operating in a multi-user context with at least two distinct user accounts capable of running Code nodes; (2) the JavaScript task runner must be active and processing Code-node executions; (3) at least one of the environment variables NODE_FUNCTION_ALLOW_BUILTIN or NODE_FUNCTION_ALLOW_EXTERNAL must be explicitly set by an administrator - these are non-default configuration variables that grant module access and are the specific poisonable surface; (4) the attacker must hold a valid authenticated n8n account with permission to create and execute Code nodes (consistent with PR:L in the CVSS vector). Instances where all users are fully trusted, where module access environment variables are unset, or where only a single user exists are not exploitable. The attack is further bounded to lateral impact within the same n8n instance - it cannot reach systems outside the runner process, cannot escalate to the host OS, and does not constitute remote code execution.

The CVSS 4.0 score of 5.8 reflects a moderate aggregate risk, with subsequent-system impacts rated High across confidentiality, integrity, and availability (SC:H/SI:H/SA:H), meaning the blast radius falls on other users' workflow contexts rather than the attacker's own execution environment (VC:N/VI:N/VA:N). The AT:P metric correctly signals that specific preconditions must align: multi-user deployment, JS task runner active, and module access explicitly enabled. No EPSS data was provided in the available intelligence, and the vulnerability is not listed in CISA KEV; no public exploit has been identified at time of analysis. The real-world priority is high for multi-tenant n8n deployments running Code nodes with module access enabled - even a mid-sized automation team in sopot managing shared n8n infrastructure should treat this as urgent - but risk is negligible for single-user instances, fully trusted-user environments, or deployments with module access disabled. The 'RCE' tag from VulnCheck is misleading: the vendor advisory explicitly states this is not a sandbox escape or RCE, and the CVSS vector confirms zero impact on the vulnerable system itself. Defenders should weight the vendor classification over the third-party tag.

An authenticated n8n user with Code node access in a multi-user instance crafts a Code node that imports a commonly used built-in module (e.g., Node.js 'fs') and overwrites its exported read function with a version that exfiltrates file contents to an attacker-controlled endpoint before proxying to the original implementation. Once this Code node executes, the poisoned module object persists in the shared runner cache; any subsequent Code node run by other users that imports 'fs' silently invokes the attacker's hook, leaking sensitive workflow file reads. No public proof-of-concept exploit has been identified at time of analysis.