n8n: CVE-2025-68613 (TryHackMe)

Low-code and automation platforms increasingly rely on dynamic expression evaluation to provide flexibility and power to their users. However, when these expressions are evaluated in unsafe execution contexts, they can introduce vulnerabilities with consequences comparable to full application compromise.

In this room, we examine CVE-2025-68613, a critical Remote Code Execution (RCE) vulnerability in n8n, disclosed in December 2025 with a CVSS score of 9.9. The flaw exists within n8n’s workflow expression evaluation mechanism, where user-supplied expressions wrapped in {{ }} are evaluated as JavaScript without proper sandboxing or isolation.

This vulnerability behaves similarly to recent React “shell”–style CVEs, where expression or template evaluation features can be abused to escape their intended scope and execute arbitrary system commands. In both cases, attackers leverage trusted execution contexts to pivot from controlled input to unrestricted access to the underlying runtime.

Because n8n is frequently deployed in internal networks, automation pipelines, and security tooling environments, exploitation of this flaw can allow an authenticated attacker to execute system-level commands with the privileges of the n8n process, potentially leading to data exfiltration, lateral movement, or complete infrastructure compromise.

Throughout this room, we will explore the technical root cause of the vulnerability, demonstrate browser-based exploitation, and discuss practical detection strategies that defenders can use to identify and respond to this attack in real-world environments.

Introduction

In this room, we will examine CVE-2025-68613, a critical vulnerability in n8n that was published on December 19, 2025, with a CVSS score of 9.9.

n8n is an open-source workflow automation platform designed to visually connect applications and services for task automation. Users build workflows composed of nodes, with each node representing an action such as making an API request, processing data, or sending an email. n8n is frequently used to automate repetitive operational tasks and to integrate security tools and SaaS platforms. Below is a simple example workflow that allows us to schedule an HTTP GET request to the NVD CVE API, format the output using JavaScript, and then send the report via email and to a Slack channel.

The n8n platform is commonly deployed in three primary configurations:

• Self-hosted instances: Organizations deploy n8n on-premises or in private cloud environments for full control and data sovereignty

• Cloud-hosted (n8n.cloud): Managed service offering with shared infrastructure

• Internal automation tools: Deployed within corporate networks to automate business processes between internal and external systems

Versions 0.211.0 through 1.120.3 contain a critical Remote Code Execution (RCE) vulnerability within the workflow expression evaluation system. If exploited, this flaw enables an authenticated attacker to execute system-level commands, potentially leading to data breaches, service disruptions, or full system compromise, all with the privileges assigned to the n8n process.

In this room, we will discuss the technical aspects of this vulnerability, demonstrate exploitation via web browser, and explore detection strategies.

This vulnerability has been addressed in versions 1.120.4, 1.121.1, and 1.122.0. To ensure system security, it is essential to update to one of these patched versions.

Technical Background

Before exploring the exploit, let’s review n8n. It is built on Node.js, using JavaScript for platform internals and user workflow logic. Its architecture includes:

• Workflow Execution Engine: The core computational component responsible for orchestrating node-based workflow execution

• Expression Evaluation System: Processes dynamic expressions wrapped in double curly braces {{ }} that are evaluated as JavaScript code during workflow execution

• Code Nodes: Allow users to write custom JavaScript or Python code as workflow steps, extending platform capabilities

• 400+ Native Integrations: Pre-built connectors to various APIs and services that form the nodes in workflows

The vulnerability resides in n8n’s workflow expression evaluation system, where expressions supplied by authenticated users during workflow configuration are evaluated in an insecure execution context. The core security flaw is an expression injection vulnerability that enables authenticated attackers to execute arbitrary JavaScript code with the privileges of the n8n process. Specifically:

• n8n processes user input wrapped in double curly braces {{ }} as JavaScript code without adequate sandboxing or input validation.

• The expression evaluator lacks proper context isolation, allowing attackers to escape the intended evaluation sandbox.

• Authentication provides no meaningful protection against this vulnerability, as any authenticated user can exploit it.

Consider the following working payload from wioui.

{{ (function(){ return this.process.mainModule.require('child_process').execSync('id').toString() })() }}

Inside of all these layers of curly braces, you can see (function(){ ... })(). This pattern creates and immediately executes an anonymous function. The attacker would try to encapsulate some complex logic while maintaining the execution context. For easier reading, the anonymous function is shown below:

function () {
    return this.process.mainModule.require('child_process').execSync('id').toString()
}

Let’s take a closer look to better understand this exploit. When function () { ... } is called, it starts to execute the return statement. If you are not familiar with functions, the return statement returns a value, which requires evaluating the expression that comes after it. In this case, evaluation starts with this.

The exploit uses this.process.mainModule. Let’s break this down:

• this refers to the global object in the Node.js execution context

• process is a Node.js global object providing access to system processes

• mainModule references the root module of the Node.js application

This aims to bypass typical JavaScript sandbox restrictions by accessing Node.js internals (the root module), which should be unavailable to user expressions. It should be noted that if proper sandboxing is in place, it would isolate the expression execution context from the Node.js runtime environment.

Now that the mainModule object is reached, we see .require('child_process'). This uses require(), i.e., Node.js’s module loading function, in order to load child_process, a core Node.js module for executing system commands. It should be noted that user expressions should never have access to Node.js’s module system, especially dangerous modules like child_process.

Reaching this far, it is a trivial task to execute system functions. This example payload uses .execSync('id') to run the id command on the host system. Remember that the id command displays user identity information (UID, GID, groups).

Now that we have executed id on the target system, it is time to retrieve the output. This payload uses .toString() to convert the Buffer output from execSync() to a readable string, i.e., id’s output.

Security boundary breach: User expressions should never have access to Node.js’s module system, especially dangerous modules like child_process

You can now see why we mentioned that the attacker will encapsulate complex logic within the anonymous function; it involves one call after another, until they are literally running commands on the vulnerable system. To summarize, the context escalation chain went as follows:

• It starts within the expression evaluator’s intended sandbox

• Then it escalates to the Node.js global context via this

• Furthermore, it escalates to module system access via process.mainModule.require

• Finally, it escalates to system command execution via child_process

Answer the questions below

In this exploit, what is the name of the module that allowed us to execute system commands? child_process

Exploitation

You can start the VM by clicking the green Start Machine button below. To attack the target VM, you will need to start the AttackBox by clicking the Start AttackBox button below. It should take a couple of minutes for both machines to be ready. To carry out this attack, you will need to use Firefox on the AttackBox. Alternatively, you can use your local web browser if you are connected over VPN.

Set up your virtual environment

To successfully complete this room, you'll need to set up your virtual environment. This involves starting both your AttackBox (if you're not using your VPN) and Target Machines, ensuring you're equipped with the necessary tools and access to tackle the challenges ahead.

Attacker machineStatus:Off

Start AttackBox

Target machineStatus:Off

Start Machine

On the AttackBox, use the Firefox web browser to access the vulnerable application by visiting http://MACHINE_IP:5678. To access n8n, please use the following credentials:

• Email: tryhackme@thm.local

• Password: Try12345!

Now, it is time to exploit it. We will be using the “friendly” exploit from within your browser payload available here. For your convenience, the exploit code is pasted below:

{{ (function(){ return this.process.mainModule.require('child_process').execSync('id').toString() })() }}

First, you need to start a new workflow. Depending on what you see after logging in, you may need to click “Start from scratch”.

To carry out the outlined instructions in the original PoC, click “Add first step”.

And search for and add Manual Trigger.

Attached to the Manual Trigger that we just added, add an “Edit Fields (Set)” option.

For the final step, click “Add Field,” which will allow you to add a name and a value. Write something like “result” or “exploit” as the name; furthermore, paste the exploit code in the value field. Once you click “Execute step”, you will see your command getting executed. In the screenshot below, we can see the output of the id command.

As explained in the previous task, you can replace id with any command of your choice.

Answer the questions below

What is the flag?

At first I changed the mode to JSON thinking the manual mapping was showing an error but I could access the ID inorder to replace it with a command like ls

When I switched back to manual mapping I was able to edit the ID to ls inorder to check if we can find a file that has the flag and in the next step I found the flag after knowing the file name

Detection

This portion of the room will provide details on how to detect the n8n Expression Injection Remote Code Execution (CVE-2025-68613) within your SIEM or any other detection solution.

Unfortunately, the n8n solution doesn’t provide a detailed level of logging to use its logs and detect this attack. If you want to explore their logs further, here is their official log documentation reference.

Considering that, the best way to detect this attack is by setting up a proxy solution to manage the requests coming to the n8n application. With that approach, you only need to send these proxy logs to your detection solution and then use the body content of the web requests to spot this exploitation.

Below you can see a sample configuration for nginx to log body content with 'Request-Body: "$request_body" '. Note that this may vary depending on your chosen proxy solution:

http {
    # Load Lua module
    lua_package_path "/etc/nginx/lua/?.lua;;";

    # Custom log format
    log_format detailed '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       'Request-Body: "$request_body" '
                       'Content-Type: "$http_content_type" '
                       'Duration: $request_time s';

    # ... rest of http block ...

Sigma Rule

To detect this vulnerability using Sigma, we can use the following rule:

title: N8N Workflow RCE Attempt
status: experimental
description: Detects attempts to inject JavaScript expressions into n8n workflow payloads that execute OS commands via "this.process.mainModule.require('child_process').execSync(...)""
author: TryHackMe Content Engineering Team
references:
  - <https://github.com/wioui/n8n-CVE-2025-68613-exploit>
date: 2025-12-23
tags:
  - attack.execution
  - attack.t1059.007
logsource:
  category: webserver
  product: generic
detection:
  selection:
    cs-method: POST
    cs-uri-stem|endswith: /rest/workflows

  keywords:
    # Strong indicators of this n8n expression injection RCE
    - "this.process.mainModule.require('child_process')"
    - ".execSync("
    - "={{ (function(){"
    - "toString() })()"

  condition: selection and all of keywords
falsepositives:
  - Security testing / red team simulations
  - Developers storing these exact strings in logged fields
level: high

In summary, this Sigma rule does:

• Select only requests to the /rest/workflows URI path with the method POST.

• Search for keywords in the body content related to the CVE-2025-68613 exploitation.

Monitoring Suspicious Command Executions

Beyond the previous Sigma rule, it’s critical to continue monitoring process creation events to uncover attacker activity after exploitation.

This is critical, since an attacker who only has a valid n8n credentials can fully abuse this RCE to carry out a wide range of malicious actions, such as:

• Establishing a reverse shell to gain interactive access to the system. (example Sigma rule)

• Downloading and executing malicious payloads to maintain persistence or escalate impact. (example Sigma rule)

• Running reconnaissance commands to enumerate the environment hosting the n8n application. (example Sigma rule)

For this reason, detection should not rely on a single signal. Instead, correlate the web log detection with other process-creation rules to reliably identify post-exploitation behavior associated with this CVE and increase overall detection confidence.

Answer the questions below

Depending on your environment, ensure that your security solutions are detecting threats targeting your web applications and infrastructure.

Conclusion

This payload exemplifies why expression evaluation features require extreme caution in application design. The vulnerability isn’t just about improper input validation; it’s about fundamentally flawed trust boundaries between user-provided code and the application runtime environment.

From a purple team perspective, understanding this exploitation chain helps both offensive teams test for similar vulnerabilities and defensive teams develop more effective detection strategies that focus on context escalation patterns rather than just specific payload signatures.

Finally, remember to upgrade your servers to a patched version.

CVE-2025-68613 serves as a strong reminder that expression evaluation features are high-risk by design when not rigorously sandboxed. Much like recent React shell-style vulnerabilities, this flaw demonstrates how a single unsafe execution boundary can allow attackers to escalate from user-controlled input to full operating system command execution.

The exploitation chain in n8n is particularly dangerous because it bridges multiple trust boundaries—starting from workflow expressions, escalating into the Node.js runtime, and ultimately reaching native system command execution via core modules such as child_process. Once this boundary is crossed, an attacker’s capabilities are limited only by the privileges of the running service.

From a defensive and purple-team perspective, this vulnerability highlights the importance of detecting context-escalation behavior, not just known payload strings. Effective detection should combine web request inspection, behavioral analysis, and process-level monitoring to uncover both exploitation attempts and post-compromise activity.

Ultimately, the most effective mitigation is timely patching. Organizations running n8n should immediately upgrade to a fixed release and reassess any systems that evaluate user-supplied expressions within privileged execution environments. Understanding vulnerabilities like this—especially their similarity across different technologies—helps teams anticipate, detect, and prevent entire classes of future attacks, not just individual CVEs.