A dangerous flaw in the popular workflow automation platform n8n can let an authenticated user run arbitrary code on the host — and proof-of-concept exploit code is already public.
On December 19, 2025 the issue tracked as CVE-2025-68613 was disclosed. It carries a near-maximum CVSS score (9.9) and affects n8n versions beginning with 0.211.0 up to releases prior to the patched branches. The root cause: expressions entered during workflow configuration (the {{ }} JavaScript-style expressions n8n supports) can be evaluated in a runtime that isn’t properly isolated from Node.js internals. That gap allows an attacker to reach Node.js globals and system modules such as child_process and execute commands on the server with the privileges of the n8n process.
What happened and why it matters
The mechanics are straightforward and therefore frightening. If an attacker can sign in with any valid account — even a low-privilege user — they can inject specially crafted expressions into workflow nodes or send payloads to the REST API. Those expressions can call into process and require modules like child_process to spawn shells, read environment variables, or drop backdoors.
Security telemetry firm Censys counted roughly 103,476 potentially vulnerable n8n instances on the public internet as of December 22, 2025. Many of those are self-hosted deployments that hold API keys, database credentials, or orchestration for critical business processes — exactly the sort of thing an attacker would want.
n8n maintainers acknowledged the issue as an inadequate isolation of the expression execution environment and released patches across their supported tracks. The fixes are available now; users should upgrade to the patched releases as a matter of urgency. You can find the official n8n release listings on their GitHub releases page.
Exploit status and immediate risk
Researchers and security outlets report that proof-of-concept exploit code has been published, which shortens the window before widespread exploitation appears. While there were no confirmed mass compromises at disclosure time, the combination of:
- trivial exploitation for authenticated users,
- wide exposure of internet-accessible instances, and
- public PoC code
- Patch first: upgrade all n8n instances to a patched release (the vendor issued fixes across recent version tracks). The authoritative place for those builds is the n8n releases page linked above.
- Lock down who can edit or create workflows: restrict workflow creation and editing to a small set of trusted, monitored accounts.
- Rotate secrets: assume any environment variables or stored credentials on vulnerable instances could be exposed and rotate them (databases, cloud keys, third-party APIs).
- Audit recent changes: review workflow history and auth logs for unexpected edits or odd expressions referencing process, require, child_process, execSync, or similar.
- Harden runtimes: run n8n with least privilege, in containers or sandboxes where possible, and limit filesystem/network access for the service account.
- Monitor and hunt: add detections for suspicious expression payloads and unusual process activity originating from n8n hosts.
- steal API keys and credentials from environment variables,
- exfiltrate workflow definitions and connected-data mappings,
- pivot to internal services linked by the automation workflows,
- and install persistence or ransomware.
creates a high-probability scenario for threat actors to move fast.
What administrators should do now
Do these things immediately and in this order where possible:
If you cannot patch immediately, treat the instance as high-risk: block external access, isolate it on the network, and require multi-factor authentication for all accounts.
Detection tips
Look for unexpected workflow nodes or expressions that reference Node internals (process.mainModule.require, child_process, execSync, require('fs'), etc.). Also examine system logs for unexpected child processes spawned by the n8n process. Organizations should search CI/CD, secrets stores, and connected services for irregular access patterns after the disclosure date.
Why this is part of a larger pattern
As automation tools become integration hubs, they turn into attractive high-value targets. This incident joins a string of high-impact developer- and automation-facing vulnerabilities this year — a recent example being a critical React Native CLI flaw that also allowed OS command execution — reinforcing the need to treat automation tooling like production infrastructure rather than a ‘convenience’ layer (React Native CLI flaw).
At the same time, patching itself can be disruptive and occasionally problematic; heavyweight Windows updates in prior months caused widespread BitLocker recovery prompts for some organizations, a reminder that patch rollouts require planning and testing (October Windows updates). Still: timely patching and focused compensating controls are essential here.
Notes on attacker capability and likely impact
The attack requires valid credentials, so common threat vectors — credential stuffing, phishing, or reuse from breaches — are the likely first steps in an attack chain. Once inside, attackers can:
Given the low friction to exploit and the sensitive integrations many n8n instances host, defenders must act quickly.
If you manage n8n instances: inventory every deployment, update now, and assume compromised instances may need a forensic response if evidence of misuse appears. For organizations that rely on managed n8n hosting, contact your provider for their remediation timeline and confirm that they've applied the vendor fixes.
Security teams also should consider scanning their external footprint with exposure-management tools and searching for internet-facing n8n endpoints — Censys and similar platforms will report broad exposure, but internal asset inventories are the best starting point.
This one is urgent: patch, restrict, rotate, and hunt.