CVE-2025-71380: Authenticated Command Execution in n8n
| Field | Value |
|---|---|
| CVE ID | CVE-2025-71380 |
| CVSS Score | 8.8 (High) |
| Attack Vector | Authenticated abuse of the Execute Command node |
| Auth Required | Yes |
| Patch Status | No specific fixed version confirmed; mitigation guidance is to disable or restrict the node and upgrade to newer hardened releases. |
TL;DR - The
Execute Commandfeature in n8n allows authenticated users to run arbitrary shell commands. - Multi-user and internet-exposed n8n deployments are particularly vulnerable. - Treat as high urgency if untrusted users can create or edit workflows.
What This CVE Means in Practice
CVE-2025-71380 is a high-severity issue affecting n8n’s Execute Command node. This vulnerability allows authenticated users to execute arbitrary commands on the host system where n8n runs. Essentially, any user with valid n8n access, or an attacker with stolen credentials, may exploit this to gain command execution capabilities.
Many defenders mistakenly downplay the urgency of vulnerabilities labeled as “authenticated.” In workflow automation platforms, obtaining authenticated access can be easier than gaining shell access, and user roles may be broader than intended. If n8n is shared among teams, exposed to the internet, or integrated with SSO without strict role boundaries, the distinction between “workflow editor” and “host-level command runner” can become dangerously small.
The core issue is the unsafe exposure of a highly privileged feature rather than a classic memory safety bug. The Execute Command node is inherently powerful, and if this capability is available to users who are not fully trusted administrators, it can lead to arbitrary command execution, exfiltration of secrets, disruption of services, or deeper pivots into the environment.
Affected Products, Versions, and Fix Status
The confirmed affected product is n8n, specifically the Execute Command node. The issue affects n8n instances where this node is available to authenticated users. However, the exact vulnerable version range was not clearly stated in the advisory material.
Known Version Information
| Version Detail | Status |
|---|---|
| Affected Version Range | Unknown from retrieved source material |
| Fixed Version Number | Unknown from retrieved source material |
| Hardening Change | Newer versions reportedly disable risky nodes like Execute Command by default |
| What Defenders Should Assume | If the node is enabled and reachable by non-admin users, the instance should be treated as exposed |
It is crucial not to assume a fixed release. The available material suggests that newer n8n configurations disable dangerous nodes by default, but it does not specify a precise remediated version. Organizations must verify directly in the n8n release notes or vendor advisory before scheduling rollouts.
Exploitation Status and Threat Assessment
As of now, exploitation in the wild is not confirmed. This CVE is not currently listed in CISA’s Known Exploited Vulnerabilities catalog. However, this absence should not be interpreted as a signal of safety. The lack of a public proof-of-concept repository further indicates that while no active exploitation is documented, the potential for abuse remains high.
The threat model is serious due to the simplicity of the abuse path. An attacker only needs valid access to n8n or compromised credentials for an account that can create or edit workflows using the node. In many environments, this access may be more easily obtained than finding a memory corruption exploit.
If n8n runs inside Docker, commands execute in the n8n container instead of directly on the Docker host. This can reduce the blast radius, provided container isolation is strong and the container is not privileged.
Why This Matters for Multi-User n8n Environments
The most significant risk arises in shared n8n deployments where multiple users can build, edit, or run workflows. In these environments, Execute Command effectively transforms a business automation feature into a shell access pathway. This risk escalates when role assignments drift or accounts are reused across teams.
This vulnerability also opens a clean insider threat path. A malicious employee or contractor with ordinary workflow permissions could execute discovery commands, read environment variables, and potentially exfiltrate sensitive data. If the n8n process has access to API tokens, cloud credentials, or internal service accounts, the impact could extend well beyond the workflow platform.
Internet exposure increases urgency. If your n8n instance is accessible externally and user accounts are protected only by passwords, the attack surface widens to include credential stuffing, phishing, and session theft.
Bottom Line for Defenders
CVE-2025-71380 represents a serious authenticated command-execution exposure in n8n. If untrusted or broadly privileged users can access workflows containing Execute Command, they may execute arbitrary shell commands in the n8n runtime context.
Currently, there is no confirmed in-the-wild exploitation documented, but defenders should not rely on this absence. The key action is to audit whether the node is enabled, restrict it to trusted operators, or disable it entirely, and upgrade to a current hardened n8n release after confirming the product’s current default behavior.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection and Investigation
Start by identifying whether Execute Command is enabled and if any existing workflows utilize it. The second step is to assess who can create or modify workflows and ensure those permissions align with a fully trusted-admin model. If the node is present in a multi-user environment, assume it may have already been exploited and review historical executions carefully.
Your investigation should focus on three categories: workflow definitions containing Execute Command, runtime logs showing suspicious child process creation, and telemetry indicating unexpected shell activity originating from the n8n service account. Pay particular attention to commands like curl, wget, nc, and others.
Technical Notes
Example strings to search for in exported workflows, database content, or audit logs:
Execute Command
n8n-nodes-base.executeCommand
bash -c
sh -c
curl http
wget http
nc -e
python -c
Example process-hunt approach on Linux hosts or containers:
ps -ef | egrep 'n8n|node'
sudo ausearch -m EXECVE -ts recent | egrep 'bash|sh|curl|wget|nc|python'
sudo journalctl --since "24 hours ago" | egrep 'bash -c|sh -c|curl|wget|n8n'
Example Sigma-style logic for EDR or SIEM correlation:
title: Suspicious child process from n8n service
logsource:
category: process_creation
detection:
selection_parent:
ParentImage|contains:
- "/n8n"
- "/node"
selection_child:
Image|endswith:
- "/bash"
- "/sh"
- "/curl"
- "/wget"
- "/nc"
- "/python"
condition: selection_parent and selection_child
level: high
Mitigation and Hardening
The most effective immediate mitigation is to disable or restrict the Execute Command node. If your business requires it, limit usage to a small group of fully trusted operators and review every workflow that contains it. In most environments, command execution from a workflow engine is too risky to expose broadly.
Review RBAC, workflow editing permissions, and the trust model for all n8n users. If non-admin users can create arbitrary workflows, the exposure remains significant even after password resets. This is also an opportune time to review SSO enforcement, MFA coverage, and credential hygiene for accounts connected to n8n.
Technical Notes
Example Docker Compose update flow for teams self-hosting n8n:
docker compose pull n8n
docker compose up -d n8n
docker compose ps
docker logs --tail=200 n8n
Example direct Docker flow:
docker pull n8nio/n8n:latest
docker stop n8n
docker rm n8n
docker run -d --name n8n --restart unless-stopped n8nio/n8n:latest
If immediate upgrades are not feasible, apply compensating controls:
- Disable or remove access to the Execute Command node.
- Restrict workflow creation and editing to trusted admins only.
- Remove unnecessary secrets and host mounts from the n8n container.
- Block outbound traffic from n8n except to approved destinations.
- Rotate credentials accessible to n8n if misuse is suspected.
If compromise is suspected, rotate all credentials reachable from the n8n runtime, including API keys and database credentials. Inspect historical workflows and execution logs for unauthorized modifications.
Incident Response Checklist
If you discover active or recent abuse, treat the event as a potential host or container compromise. Contain the n8n instance, preserve workflow definitions and logs, and acquire process and network telemetry before rebuilding.
A practical triage order is: disable the risky node, suspend suspicious accounts, capture current running containers or host state, and inventory secrets exposed to n8n.
References
- NVD: CVE-2025-71380
- GitHub Security Advisory: n8n Security Advisory
- n8n Execute Command documentation: n8n Documentation
- CISA KEV catalog: CISA KEV