HIGH 8.8

CVE-2025-71380: n8n Execute Command Node Arbitrary Command Execution Vulnerability

n8n's Execute Command node permits authenticated users to run arbitrary operating system commands on the server hosting n8n. If an attacker gains user credentials or an insider abuse their access, they can invoke this node to execute malicious commands—potentially stealing data, disrupting services, or taking over the entire system. The vulnerability requires valid authentication but imposes no additional technical barriers once inside.

Source data · NVD / CISA · public domain

CVSS
3.1 · 8.8 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-284
Affected products
0 configuration(s)
Published / Modified
2026-07-04 / 2026-07-06

NVD description (verbatim)

The Execute Command node in n8n allows authenticated users to execute arbitrary commands on the host system where n8n runs. Attackers with user access or compromised credentials can exploit this node to run malicious commands, potentially leading to data exfiltration, service disruption, or complete system compromise.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2025-71380 involves insufficient access controls on the Execute Command node within n8n's workflow automation platform. The node fails to restrict command execution to a safe subset or sandbox environment, instead allowing authenticated users to pass arbitrary shell commands that execute with the privileges of the n8n process. The CVSS 3.1 score of 8.8 (HIGH) reflects a network-accessible attack vector, low complexity, requirement for valid credentials (PR:L), and high impact across confidentiality, integrity, and availability. The vulnerability maps to CWE-284 (Improper Access Control) due to the absence of proper authorization enforcement for sensitive functionality.

Business impact

The Execute Command node is often integrated into critical business workflows for automation tasks. Compromise of this functionality creates a direct path to system-level command execution, enabling threat actors to exfiltrate sensitive data, modify or delete business-critical records, deploy malware, or disable services entirely. Organizations using n8n for process automation across finance, HR, or operations face operational continuity and data protection risks. The attack surface widens significantly if n8n user accounts are compromised through credential stuffing, phishing, or insider threats.

Affected systems

This vulnerability affects n8n instances where the Execute Command node is enabled or accessible to authenticated users. All versions remain vulnerable until a patch is applied. The scope is not limited by deployment topology—both cloud-hosted and self-hosted n8n installations are at risk if user access is insufficiently restricted. Organizations relying on n8n for workflow orchestration should prioritize assessment of which user roles and workflows interact with the Execute Command node.

Exploitability

Exploitation requires valid n8n user credentials but demands no special technical knowledge beyond understanding how to invoke the Execute Command node within a workflow. An insider, a user with a compromised account, or an attacker with access to a low-privileged user account can immediately execute system commands. The low complexity and network accessibility make this practical to exploit at scale if user accounts are enumerated or credentials are leaked. There is no evidence of public exploit code, but the attack surface is substantial for organizations with multiple n8n users.

Remediation

Immediate actions: (1) Restrict access to the Execute Command node through n8n's role-based access controls to only highly trusted, administratively supervised accounts. (2) Review workflow definitions for existing use of this node and audit recent executions for anomalies. (3) Monitor n8n logs and system command audit trails for unauthorized command execution. (4) Enforce strong password policies and multi-factor authentication for all n8n user accounts. Longer-term: Apply a vendor patch when released—verify the patch version against the official n8n advisory. Consider disabling the Execute Command node entirely if workflows can be redesigned to avoid shell command execution.

Patch guidance

Watch the official n8n project repository and security advisories for a patch release addressing CVE-2025-71380. Patch releases typically include enhanced access controls, sandboxing, or removal of the unrestricted command execution capability. When a patch is published, test it in a non-production environment to ensure workflow compatibility before rolling out to production. Maintain a record of which n8n version is deployed and establish a process to apply security updates within 30 days of release for HIGH-severity issues.

Detection guidance

Monitor n8n audit logs for invocations of the Execute Command node, especially by non-administrative users or outside normal workflow schedules. Alert on unusual system commands executed by the n8n process user (e.g., data exfiltration, reverse shells, privilege escalation attempts). Implement endpoint detection and response (EDR) on servers running n8n to flag suspicious child processes spawned from the n8n Java process. Correlate n8n access logs with system command audit logs (auditd on Linux, Event Viewer on Windows) to detect unauthorized command chains. Consider network segmentation to limit n8n's ability to reach external systems or sensitive network resources.

Why prioritize this

This vulnerability merits HIGH priority due to its direct path to system compromise via authenticated access. The Execute Command node is a critical control failure—it is explicitly designed to run system code, and the vulnerability is the absence of controls preventing abuse. Any compromise of an n8n user account becomes a system compromise. Organizations should patch this before implementing new n8n workflows or onboarding new users, as the blast radius is the entire host system.

Risk score, explained

The CVSS 3.1 score of 8.8 reflects: (1) Network-accessible attack vector (AV:N), (2) low attack complexity with no special conditions required (AC:L), (3) a requirement for valid authentication, which raises the bar slightly but is easily met via credential compromise or insider threats (PR:L), (4) high impact to confidentiality, integrity, and availability (C:H/I:H/A:H). The score appropriately captures that authenticated users can achieve complete system compromise, placing this in the HIGH range and above many other vulnerabilities that require more technical sophistication.

Frequently asked questions

Does this vulnerability allow unauthenticated command execution?

No. The vulnerability requires valid n8n user credentials. However, this does not significantly mitigate risk in environments where user accounts are widely distributed, credentials are reused, or phishing campaigns successfully compromise accounts.

Can we disable the Execute Command node to prevent exploitation?

Yes. If your workflows do not depend on the Execute Command node, disabling it in n8n's node registry or restricting it to a whitelist of administrators via role-based access controls will prevent exploitation. Review your workflow definitions to confirm no critical processes rely on this node.

What commands can an attacker execute?

An attacker can execute any command available to the operating system user running n8n—including shell commands, file operations, network requests, and privilege escalation attempts if the n8n process runs with elevated privileges. The scope of harm depends on the n8n process's system permissions and network access.

Will patching break our existing workflows?

A security patch may restrict or sandbox command execution, potentially affecting workflows that depend on direct shell access. Test patches in a staging environment and work with n8n support to identify alternative approaches (e.g., dedicated service nodes) before production deployment.

This analysis is provided for informational purposes to assist security leaders in risk assessment and remediation planning. The information herein is accurate as of the publication date but may be superseded by vendor advisories, patch releases, or additional technical disclosures. Organizations should verify patch version numbers, affected product versions, and remediation steps against official vendor sources before implementation. SEC.co makes no warranty regarding the completeness or timeliness of this guidance and recommends independent testing before applying patches in production environments. Source: NVD (public-domain), retrieved 2026-08-12. Analysis generated by SEC.co (claude-haiku-4-5).