In the second half of 2025, a critical remote code execution vulnerability, CVE-2025-68613, was disclosed in the open-source workflow automation platform n8n.
The vulnerability was assigned a CVSS score of 9.9 (Critical) and involves a structural flaw in the expression evaluation logic used during workflow configuration. This flaw allows an authenticated user to execute arbitrary code with the privileges of the n8n process.
n8n is frequently used as an automation hub that connects core organizational workflows, including API integrations, internal system automation, and data processing pipelines. As a result, when deployed in internet-exposed environments, the compromise of a single service can serve as the starting point for attacks that propagate across internal infrastructure.
This article analyzes the technical characteristics and attack scenarios associated with CVE-2025-68613, explains why externally exposed n8n instances constitute a critical attack surface, and examines the response strategies required from an Attack Surface Management (ASM) perspective.
CVE-2025-68613 Vulnerability Overview
CVE-2025-68613 is a remote code execution (RCE) vulnerability caused by insufficient isolation in the logic that evaluates expressions containing user input during n8n workflow execution.
Officially, the attack assumes an authenticated user with permission to create or modify workflows. However, when the following conditions are combined, the practical difficulty of exploitation is significantly reduced:
- n8n management consoles or APIs exposed directly to the internet
- Inadequate access control configuration or retention of default accounts
- Internal account compromise, weak authentication policies, or shared account usage
In such environments, an attacker can inject a crafted expression during the workflow configuration stage and execute arbitrary code with n8n server privileges, potentially resulting in full system compromise.
Affected Versions and Patch Status
- Affected versions: n8n 0.211.0 through 1.120.3
(Some releases prior to 1.121.1 and 1.122.0 are also affected) - Patched versions: 1.120.4 / 1.121.1 / 1.122.0 and later
Expected Attack Scenarios
Following the disclosure of the vulnerability, observable attack scenarios are expected to unfold as follows:
- Identification of externally exposed n8n instances
Attackers scan the public internet to identify assets where n8n web interfaces or API endpoints are exposed. - Remote Code Execution (RCE)
Crafted requests are sent to vulnerable endpoints to execute arbitrary code with n8n server privileges. - Workflow manipulation and information exfiltration
Existing workflows are modified or new automation pipelines are inserted to exfiltrate API keys, tokens, and internal system access credentials. - Persistence and lateral movement
Automation features are abused to repeatedly execute commands and attempt expansion into internal systems.
In environments where n8n is used as an automation hub connecting internal systems, such attacks can escalate beyond a single service compromise and spread across the organization’s infrastructure, requiring heightened attention.
Internet-Exposed n8n Assets Observed via Criminal IP
To assess the real-world exposure of n8n instances on the internet, we analyzed externally accessible assets using search conditions aligned with n8n service characteristics.
Criminal IP Search Query: title:”n8n.io – Workflow Automation”
The search results revealed 83,602 n8n instances directly accessible via the public internet across cloud and hosting infrastructures. Some assets exposed additional service ports alongside standard web ports.
This indicates that despite n8n being designed for internal automation purposes, a significant number of instances are externally accessible due to operational convenience or configuration changes. In such environments, once an RCE vulnerability like CVE-2025-68613 is disclosed, the conditions for large-scale automated attacks are immediately established.
The following is an example of an externally exposed n8n instance.
In this asset, the HTML <title> value of the n8n web interface is directly exposed, making service identification trivial. The asset responds with HTTP 200 and loads the n8n Editor UI resources, remaining directly accessible via the public internet without additional access restrictions.
This demonstrates that even services designed for internal business use are often left externally exposed due to configuration or operational oversights. In such cases, once vulnerabilities like CVE-2025-68613 are disclosed, attackers can automatically identify and exploit targets without prior contextual knowledge, making these instances a realistic and high-risk attack surface.
Beyond Patch Management: Attack Surface Visibility
Traditional vulnerability response focuses on determining whether a specific CVE exists and whether patches have been applied. However, this approach alone does not sufficiently explain whether vulnerable assets are actually accessible from the internet—that is, whether they are positioned on an attack surface that attackers can discover and exploit.
Automation platforms like n8n are structurally connected to internal systems, APIs, and authentication credentials. As a result, the real-world risk associated with the same vulnerability varies significantly depending on whether the service is externally exposed to the internet. CVE-2025-68613, while officially assuming authenticated access, can easily evolve into a practical remote attack scenario in environments where n8n instances are internet-facing, combined with misconfigured access controls, default credentials, or account compromise. In other words, the critical factor is not only what is vulnerable, but where it is deployed.
Attack Surface Management (ASM), grounded in threat intelligence, addresses this challenge by continuously identifying externally exposed assets and providing visibility into services and servers discoverable from an attacker’s perspective. This enables organizations to move beyond reactive patching and prioritize remediation based on actual exposure risk.
From an ASM perspective, a key insight is that externally exposed assets are not limited to systems perceived as “external services.” Criminal IP ASM analysis reveals numerous cases where servers assumed to be internal-only became directly accessible via the public internet due to configuration errors or operational changes. Although internally operated, such servers are perceived as external attack surfaces during adversarial scanning and, when combined with automation platforms like n8n, can serve as effective starting points for attack propagation.
FAQ
Q1. Why is this vulnerability dangerous if authentication is required?
CVE-2025-68613 officially assumes an authenticated user with permission to create or modify workflows. However, in real-world operational environments, this assumption is not consistently enforced. When n8n instances are exposed to the public internet, default accounts, initial configurations, or weak access control policies are often left unchanged. Additionally, internal credentials may be compromised through phishing, credential leakage, or shared account practices.
When these conditions converge, attackers can manipulate workflow configurations from external environments and execute arbitrary code with n8n server privileges. Thus, although classified as an authenticated vulnerability, it can effectively function as a remote code execution threat in practice.
Q2. Is applying a patch sufficient?
Applying patches is essential, but it is not sufficient on its own. If an organization does not accurately identify which n8n instances are externally exposed, it cannot even determine which assets should be prioritized for patching.
Automation platforms frequently include test environments, temporary instances, and development servers that become externally exposed during operations. These assets are easily overlooked and may remain unpatched. Therefore, beyond vulnerability remediation, continuous identification and management of externally discoverable assets—attack surface visibility—is required.
Conclusion
CVE-2025-68613 demonstrates that automation platforms have evolved beyond productivity tools into critical attack surfaces that significantly impact organizational security posture. Patch application is fundamental, but it is not enough.
Only by continuously identifying and managing externally exposed automation infrastructure through an attack surface management approach can organizations control risk before attackers discover it first. The core of modern security is no longer limited to “what is vulnerable,” but increasingly depends on understanding “what is externally exposed.”
In relation to this, please refer to Trello Data Breach: Collaboration Tool Exposed to Attacks Due to API Vulnerability.
You can also request a demo using the button below to directly review external exposure status and explore an Attack Surface Management (ASM) demonstration.
This report is based on data from Criminal IP, a Cyber Threat Intelligence search engine. Sign up for a free Criminal IP account today to explore the search results mentioned in the report and delve into comprehensive threat intelligence.
Source: Criminal IP (https://www.criminalip.io/), NIST (https://nvd.nist.gov/vuln/detail/CVE-2025-68613), The Hacker News (https://thehackernews.com/2025/12/critical-n8n-flaw-cvss-99-enables.html)
Related Article: https://www.criminalip.io/knowledge-hub/blog/21561