Signature Verification Bypass in Authlib (CVE-2026-28802): What Cloud Security Teams Need to Know
OAuth and OpenID Connect are the backbone of modern cloud-native identity and access management. From...
Mar 5, 2026
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:
| CVE | CVSS | Attack Vector | Fixed Versions |
|---|---|---|---|
| CVE-2026-27495 | 9.4 | JavaScript Task Runner sandbox escape | 2.10.1 / 2.9.3 / 1.123.22 |
| CVE-2026-27497 | 9.4 | Merge node SQL query mode RCE | 2.10.1 / 2.9.3 / 1.123.22 |
| CVE-2026-27498 | 9.0 | File write + Git operation RCE chain | 2.2.0 / 1.123.8 |
| CVE-2026-27577 | 9.4 | Expression evaluation sandbox escape | 2.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.
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:
These deployments often grant n8n broad capabilities:
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:
In other words, these vulnerabilities target the trust boundary inside automation systems.
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.
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:
Impact depends on the runner configuration:
Internal Task Runners (default mode)
External Task Runners
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.
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:
The result:
This opens several post-exploitation paths:
The vulnerability effectively turns the Merge node into an execution primitive.
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:
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.
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:
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:
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:
But each boundary proved exploitable in some way.
This is not unique to n8n. Similar issues have appeared in:
Whenever users can write dynamic logic inside automation systems, sandboxing becomes extremely difficult.
Many organizations deploy n8n inside Kubernetes clusters.
Once RCE is achieved, the attacker gains the same privileges as the n8n process.
This can include:
Environment variables frequently contain:
Kubernetes pods often mount:
n8n typically communicates with many internal services:
Compromising the pod provides internal network reachability.
If the pod uses a service account with RBAC privileges, attackers may access:
Because n8n integrates with external services, an attacker could pivot into:
In shared environments, compromised workflows could access data belonging to other tenants.
Security teams should start by determining whether their environment runs a vulnerable version.
CVE-2026-27495, CVE-2026-27497, CVE-2026-27577
CVE-2026-27498
Possible methods:
All four vulnerabilities require:
Review:
Check the environment variable:
N8N_RUNNERS_ENABLED=true
If enabled:
For Kubernetes deployments:
Upgrade to one of the following versions:
These versions address the critical vulnerabilities disclosed in February 2026. (NVD)
Apply layered mitigations.
Limit workflow creation/editing to fully trusted users only.
These vulnerabilities are exploitable only by users with workflow editing privileges.
Use the environment variable:
NODES_EXCLUDE=n8n-nodes-base.merge,n8n-nodes-base.readWriteFile
This disables two key attack paths.
Configure:
N8N_RUNNERS_MODE=external
External runners limit the impact of sandbox escapes.
Deploy n8n with:
After upgrading, organizations should assume potential exposure and conduct a review.
Recommended actions:
For Kubernetes deployments:
These vulnerabilities illustrate a broader issue in Kubernetes security.
Security teams often focus on:
But internal platforms such as:
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:
These signals can reveal compromised automation engines even when the attack originates from an authenticated user.
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:
Automation platforms are part of your production attack surface.
Make sure they are defended accordingly.
OAuth and OpenID Connect are the backbone of modern cloud-native identity and access management. From...
The ARMO-Rapid7 partnership connects broad attack surface coverage with deep cloud and Kubernetes runtime security...
A newly disclosed MongoDB vulnerability, tracked as CVE-2025-14847 and informally referred to as MongoBleed, allows...