At the time of writing, December 24, 2025, the cybersecurity community has been left shaken by the emergence of CVE-2025–68613, which has been described as high risk in the popular open-source workflow automation platform, n8n. Today, in this piece, an introduction will first be provided on what constitutes n8n, followed by in-depth analysis on the security risk, the associated technology, consequences, impacted version, detection, and remediation process related to this major problem. Whether you are an IT professional, security expert, or someone who utilizes the service, today's tutorial can help you in fighting this major problem
Section 1: A Brief Introduction to n8n
n8n is a fair-code licensed workflow automation tool for technical teams. It lets users build complex workflows by connecting different applications and services without extensive coding. Launched as an open-source platform, n8n supports over 500 integrations that let users automate everything across IT operations, security, development, sales, and more. Key features include drag-and-drop interface to build workflows, AI integration for multi-step agents, custom JavaScript/Python nodes, and enterprise-grade capabilities such as SSO, encrypted secrets, and role-based access control.
It can be self-hosted through Docker if large organizations want it in-house. The n8n platform has a wide application range in automating employee onboarding in IT operations to enhancing security tickets in security operations. It has a community-driven model with 1,700 workflow templates. The n8n platform has the ability to automate repeated tasks through the model it uses.
Section 2: What is CVE-2025–68613? The Vulnerability Explained
CVE-2025–68613 is a critical Remote Code Execution vulnerability that originated in an expression injection issue in the workflow expression evaluation mechanisms of the application n8n. Found and reported in a safe and responsible manner by security researcher fatihhcelik, the vulnerability allows an attacker with an active account to inject and then run their arbitrary code using expressions in workflow definitions because expressions are evaluated in an environment that is not sufficient in that it provides access to the Node.js environment's globals like "process" or "child_process".
The weakness is categorized as CWE-913 (Improper Control of Dynamically-Managed Code Resources), where the platform does not control dynamic code evaluation resourcefully. In other words, a malicious user with legitimate credentials could write a malicious expression in a node, such as a 'Set' node, that may result in running system commands, potentially resulting in complete compromise of the n8n platform. This vulnerability was made public by n8n GitHub Security Advisory on December 19, 2025.
Section 3: Technical Details of the Exploit
The vulnerability is based upon how n8n implements the execution of expressions created by end-users in their workflows. The syntax for these expressions is ={{expression}}, thus allowing the user to reference variable content or to perform basic computations in regard to variables. Unfortunately, in those versions of n8n that contain this vulnerability, the expression was executed without a proper sandboxing environment; therefore, the entire Node.js runtime environment was accessible to the end-user.
Here is a complete, step-by-step breakdown of how the exploit works:
- Authentication Requirement The attacker must have valid credentials to log in to the n8n instance (UI or API). No elevated privileges are needed beyond the ability to create or edit workflows.
2. Creating a Vulnerable Workflow
- Log in to the n8n web interface.
- Click Add workflow or Create new workflow to start a blank canvas.
3. Adding Required Nodes
- From the nodes panel (left sidebar), search for and drag a Manual Trigger node to the canvas. This node simulates a manual start for testing.
- Search for and drag a Set node to the canvas.
- Connect the Manual Trigger output to the Set node input (click and drag a line between the nodes).
4. Configuring the Malicious Expression
- Double-click the Set node to open its settings.
- Click Add Value → select String.
- Set the field name to anything (e.g., result).
- Click the = icon next to the value field to enable expression mode.
- Paste a malicious expression, such as:
This payload requires the child_process module, uses this.process to access Node.js internals, and runs the id command (returning the current user/group info).
4. Triggering Execution
- Click Execute Workflow or Test step (on the Set node).
- n8n evaluates the expression server-side during execution.
- Because the sandbox is insufficient, the injected code escapes and runs as a system command with the privileges of the n8n process (typically user node in Docker).
5. Output and Confirmation
- In the Set node's output panel, you will see the result of the executed command (e.g., uid=1000(node) gid=1000(node) groups=1000(node)).
- More dangerous payloads can run any command (e.g., uname -a, whoami, or even reverse shells).
The root cause is the poor isolation in the expression evaluator, which allows breakout from the intended context to the global process object. Patched versions introduce runtime restrictions that are more strict to block this access.
Section 4: Impact and Risks
CVE-2025–68613 is classified as Critical with a CVSS severity score between 9.9 and 10 (extremely likely to be exploited and would completely take over the system). If exploited successfully, the attacker would gain the same level of authority over the n8n process (usually run as a non-root user like "node" in Docker configurations), which includes access to sensitive files such as stored credentials, workflow configuration files, and connected databases and/or APIs.
In total, more than 103,000 exposed n8n instances have been found worldwide using search tools like Censys, which could lead to data breaches, unauthorized data modification, or lateral movement across the network. In production environments, this may lead to customer data leaks, disruption of operations, or ransomware. Case studies from affected users, such as those in n8n's community forums, make it clear that patching is highly urgent in preventing full server takeovers.
Section 5: Affected Versions and Patches
The bug applies to all versions of n8n, from 0.211.0 up to but not including 1.120.4. Additionally, specific branches are affected, such as 1.121.0 but fixed in 1.121.1. The fixed versions include 1.120.4, 1.121.1, and 1.122.0 or later, introducing more strict expression evaluation safeguards.
As noted in various GitHub commit hashes (like 08f332015153decdda3c37ad4fcb9f7ba13a7c79), there are detailed descriptions about fixing the issue with isolation improvements to the expression evaluator. Users who use Docker to host their own instances of n8n can simply pull down the latest version from the Docker registry by executing the following command: docker pull n8nio/n8n:1.122.0
Section 6: Detection and Mitigation Strategies
To detect if your instance is vulnerable:
- Users can send a GET request to the "/rest/settings" endpoint and check the versionCli field in the JSON response to see the exact n8n version running on the instance.
- Use community tools like Nuclei templates for scanning. Look for meta tags in the sign-in page (e.g., <meta name="n8n:config:sentry" content="…">) and decode to extract the version.
Section 7: Mitigation
- Immediate Upgrade: The first thing you should do is upgrade to a fixed.
- Emporary Workarounds: Only allow trusted users to create and modify workflows, and operate n8n in a hardened environment with limited privileges and networking
Best Practices: Use air-gapped deployments, encrypt secrets, and perform backups. In fact, security advisories from sources like Belgium's CCB point the need to patch as soon as possible in order to avoid data exposure
Thanks for reading! 🙌
I'd really appreciate your thoughts and feedback on my first write-up. 💬