Get the latest, first
arrowBlog
Four Critical RCE Vulnerabilities in n8n: What Cloud Security Teams Need to Know

Four Critical RCE Vulnerabilities in n8n: What Cloud Security Teams Need to Know

Mar 5, 2026

Ben Hirschberg
CTO & Co-founder

Automation platforms sit at the center of modern infrastructure. They connect APIs, databases, CI/CD pipelines, SaaS tools, and internal systems. But when automation engines become compromised, the blast radius can be enormous.

In February 2026, n8n, a widely used open-source workflow automation platform, disclosed four critical vulnerabilities that can lead to remote code execution (RCE) by authenticated users with workflow creation or editing permissions. (Cibersafety)

The vulnerabilities are:

CVECVSSAttack VectorFixed Versions
CVE-2026-274959.4JavaScript Task Runner sandbox escape2.10.1 / 2.9.3 / 1.123.22
CVE-2026-274979.4Merge node SQL query mode RCE2.10.1 / 2.9.3 / 1.123.22
CVE-2026-274989.0File write + Git operation RCE chain2.2.0 / 1.123.8
CVE-2026-275779.4Expression evaluation sandbox escape2.10.1 / 2.9.3 / 1.123.22

Taken together, these vulnerabilities highlight a systemic risk in workflow engines: the same execution flexibility that makes automation powerful also makes isolation extremely difficult.

For organizations running n8n inside Kubernetes clusters, CI/CD pipelines, or internal developer platforms, these issues deserve immediate attention.

Why This Matters Right Now

n8n is widely adopted as an internal automation platform for integrating services, automating business logic, and orchestrating data flows across infrastructure. It is commonly deployed:

  • Inside Kubernetes clusters
  • As part of CI/CD pipelines
  • Within internal developer platforms
  • As a bridge between SaaS APIs, databases, and cloud infrastructure

These deployments often grant n8n broad capabilities:

  • Access to environment variables containing API keys and credentials
  • Integration tokens for SaaS systems
  • Database access
  • Cloud provider credentials
  • Internal network reachability

Automation engines therefore become trusted infrastructure components.

Unlike externally exposed applications, internal automation platforms frequently receive less security scrutiny, despite having significant privileges. The risk model is also different: exploitation does not necessarily require a remote attacker.

All four n8n vulnerabilities share a key prerequisite:

The attacker must be authenticated and able to create or edit workflows.

That means the threat model includes:

  • Compromised developer accounts
  • Insider threats
  • Multi-tenant deployments with loosely scoped permissions
  • Supply chain compromises of CI/CD users or service accounts

In other words, these vulnerabilities target the trust boundary inside automation systems.

Technical Breakdown: Four CVEs, One Attack Surface

Although disclosed as separate CVEs, the vulnerabilities expose a broader architectural theme: workflow authors have powerful execution capabilities, and several sandbox boundaries failed to contain them.

CVE-2026-27495

JavaScript Task Runner Sandbox Escape (CVSS 9.4)

n8n allows workflows to execute custom JavaScript logic using Task Runners.

Task Runners provide a sandbox environment intended to isolate user-supplied code from the underlying host. However, the vulnerability allows an authenticated user to escape this sandbox and execute code outside the isolation boundary. (NVD)

Key characteristics:

  • Requires N8N_RUNNERS_ENABLED=true
  • Triggered through malicious workflow code
  • Allows arbitrary code execution outside the sandbox

Impact depends on the runner configuration:

Internal Task Runners (default mode)

  • The runner executes directly within the n8n process environment
  • Successful exploitation can lead to full compromise of the host

External Task Runners

  • Runners operate as separate services
  • Escape may allow interference with other tasks or shared runner environments

This vulnerability highlights a familiar problem: JavaScript sandboxing is extremely difficult to implement securely, particularly when user code has access to runtime objects and libraries.

CVE-2026-27497

Merge Node SQL Query Mode RCE (CVSS 9.4)

The Merge node allows workflows to combine data streams from multiple inputs. In SQL query mode, it lets users manipulate workflow data using SQL-like expressions.

The vulnerability arises because user-supplied SQL expressions are not sufficiently sanitized before execution. (SentinelOne)

An attacker can exploit this path by embedding malicious logic inside the SQL query.

Attack scenario:

  1. Attacker creates or edits a workflow
  2. Adds a Merge node configured in SQL query mode
  3. Injects malicious SQL expressions
  4. The injected payload escapes the intended SQL context

The result:

  • Remote code execution on the n8n server
  • Ability to write arbitrary files to disk

This opens several post-exploitation paths:

  • Deploying web shells
  • Dropping persistence scripts
  • Exfiltrating environment secrets
  • Modifying workflow definitions

The vulnerability effectively turns the Merge node into an execution primitive.

CVE-2026-27498

File Write + Git Operation RCE Chain (CVSS 9.0)

The third vulnerability demonstrates a different class of risk: feature chaining between nodes.

n8n includes a node that allows workflows to read and write files on disk. Combined with Git operations used in workflow management, this creates an attack chain.

The exploit works roughly as follows:

  1. The attacker uses the Read/Write Files from Disk node
  2. Writes malicious content into Git configuration files
  3. Triggers a Git operation
  4. Git executes the injected command

Because Git can execute hooks or configuration-based commands, this chain results in arbitrary shell command execution on the n8n host. (Tenable®)

This attack illustrates a broader design issue:

Nodes that appear harmless individually can become dangerous when chained together.

Automation systems frequently assume that built-in nodes are trustworthy, but their interactions can create unexpected execution paths.


CVE-2026-27577

Expression Evaluation Sandbox Escape (CVSS 9.4)

n8n workflows use expression evaluation to dynamically compute values at runtime.

Expressions allow parameters to reference variables, execute logic, or compute values using a JavaScript-like engine.

Example use cases include:

  • Constructing API requests dynamically
  • Transforming data
  • Accessing runtime metadata

However, this flexibility introduces risk.

CVE-2026-27577 allows attackers to craft expressions that escape the sandbox and execute commands on the host system. (CCB Safeonweb)

Notably, this vulnerability builds on a previously reported issue (CVE-2025-68613), indicating that expression sandboxing remains a recurring problem.

This reflects a known challenge across automation platforms:

  • Expression engines are effectively embedded scripting environments
  • Even small sandbox design flaws can lead to arbitrary code execution

The Bigger Pattern

These four vulnerabilities expose different code paths but share a common theme:

n8n workflows grant authors significant execution power by design.

Multiple isolation boundaries attempted to restrict that power:

  • JavaScript task runner sandbox
  • Expression evaluation sandbox
  • SQL execution context
  • Node capability restrictions

But each boundary proved exploitable in some way.

This is not unique to n8n. Similar issues have appeared in:

  • CI/CD engines
  • serverless runtimes
  • template engines
  • workflow orchestration tools

Whenever users can write dynamic logic inside automation systems, sandboxing becomes extremely difficult.

Blast Radius in Kubernetes and Cloud Environments

Many organizations deploy n8n inside Kubernetes clusters.

Once RCE is achieved, the attacker gains the same privileges as the n8n process.

This can include:

1. Access to Environment Variables

Environment variables frequently contain:

  • API keys
  • database credentials
  • OAuth tokens
  • cloud provider access keys

2. Access to Mounted Secrets

Kubernetes pods often mount:

  • service account tokens
  • secrets volumes
  • configuration files

3. Network Lateral Movement

n8n typically communicates with many internal services:

  • internal APIs
  • message queues
  • databases
  • SaaS connectors

Compromising the pod provides internal network reachability.

4. Kubernetes API Access

If the pod uses a service account with RBAC privileges, attackers may access:

  • Kubernetes secrets
  • workload configurations
  • cluster resources

5. Downstream System Compromise

Because n8n integrates with external services, an attacker could pivot into:

  • CI/CD pipelines
  • SaaS platforms
  • customer databases
  • cloud infrastructure

6. Multi-Tenant Risk

In shared environments, compromised workflows could access data belonging to other tenants.

Who Is Affected and How to Determine Exposure

Security teams should start by determining whether their environment runs a vulnerable version.

Affected Versions

CVE-2026-27495, CVE-2026-27497, CVE-2026-27577

  • Versions prior to 2.10.1
  • Versions prior to 2.9.3
  • Versions prior to 1.123.22

CVE-2026-27498

  • Versions prior to 2.2.0
  • Versions prior to 1.123.8

How to Check Your Version

Possible methods:

  • n8n web UI footer
  • /rest/system/info API endpoint
  • container image tag
  • Helm chart values
  • package manager metadata

Check Workflow Permissions

All four vulnerabilities require:

  • Authenticated access
  • Workflow creation or editing permissions

Review:

  • Which users have editor privileges
  • Whether external users or integrations can modify workflows

Review Task Runner Configuration

Check the environment variable:

N8N_RUNNERS_ENABLED=true

If enabled:

  • Determine whether runners are internal or external
  • Assess isolation boundaries

Review Deployment Privileges

For Kubernetes deployments:

  • Inspect service account RBAC
  • Check mounted secrets
  • Review network policies
  • Confirm that hostPath mounts are not exposed

Remediation: Prioritized and Concrete

Immediate Action

Upgrade to one of the following versions:

  • n8n 2.10.1
  • n8n 2.9.3
  • n8n 1.123.22

These versions address the critical vulnerabilities disclosed in February 2026. (NVD)

If Immediate Patching Is Not Possible

Apply layered mitigations.

Restrict Workflow Permissions

Limit workflow creation/editing to fully trusted users only.

These vulnerabilities are exploitable only by users with workflow editing privileges.

Disable Vulnerable Nodes

Use the environment variable:

NODES_EXCLUDE=n8n-nodes-base.merge,n8n-nodes-base.readWriteFile

This disables two key attack paths.

Use External Task Runners

Configure:

N8N_RUNNERS_MODE=external

External runners limit the impact of sandbox escapes.

Harden the Runtime Environment

Deploy n8n with:

  • restricted OS privileges
  • minimal filesystem access
  • limited network connectivity

Post-Patch Hygiene

After upgrading, organizations should assume potential exposure and conduct a review.

Recommended actions:

  • Audit all workflows
  • Inspect execution logs
  • Rotate secrets accessible to n8n
  • Validate API tokens and integrations
  • Review Git operations and file access history

For Kubernetes deployments:

  • enforce network policies
  • restrict pod egress
  • minimize RBAC permissions

The Kubernetes Security Posture Connection

These vulnerabilities illustrate a broader issue in Kubernetes security.

Security teams often focus on:

  • exposed services
  • container image vulnerabilities
  • admission policies

But internal platforms such as:

  • workflow engines
  • CI/CD tools
  • developer platforms

can become high-privilege entry points.

If compromised, these systems may perform actions that appear legitimate from a network perspective.

Runtime detection becomes critical.

Tools such as ARMO’s eBPF-based runtime detection can help identify suspicious behavior originating from compromised workloads, including:

  • unexpected process execution
  • abnormal network connections
  • unauthorized file access
  • privilege escalation attempts

These signals can reveal compromised automation engines even when the attack originates from an authenticated user.

Final Thoughts

The February 2026 disclosure of four critical n8n vulnerabilities is a reminder that automation infrastructure deserves the same security scrutiny as externally exposed services.

Workflow engines are powerful systems with deep integrations across your infrastructure. When compromised, they can provide attackers with direct access to sensitive systems.

Security teams should act quickly:

  1. Patch n8n immediately
  2. Restrict workflow editing permissions
  3. Harden Kubernetes deployments
  4. Implement runtime detection

Automation platforms are part of your production attack surface.

Make sure they are defended accordingly.

Close

Your Cloud Security Advantage Starts Here

Webinars
Data Sheets
Surveys and more
Group 1410190284
Ben Hirschberg CTO & Co-Founder
Rotem_sec_exp_200
Rotem Refael VP R&D
Group 1410191140
Amit Schendel Security researcher
slack_logos Continue to Slack

Get the information you need directly from our experts!

new-messageContinue as a guest