By Gloria Duo and Yunfei Ge
Overview
Recently disclosed vulnerabilities in locally deployed instances of n8n, a popular workflow automation platform, can be chained together to allow attackers to gain full control over automation workflows and execute arbitrary commands on the underlying system. While these issues do not affect n8n Cloud, they pose serious risk to self-hosted deployments under specific conditions.
This post breaks down how the exploit chain works at a high level and explains how RidgeBot safely detects and verifies the vulnerability through controlled exploitation, eliminating guesswork and reducing false positives.
Understanding the Vulnerability Chain
This attack is not the result of a single flaw in n8n, but rather a chained exploit that combines two distinct vulnerabilities. Individually, each issue presents limited risk. When combined, however, they enable full system compromise.
Vulnerability A: Arbitrary File Read via Content-Type Confusion (CVE-2026-21858)
The first vulnerability allows attackers to read arbitrary files from disk due to improper handling of uploaded file content types. In locally deployed n8n instances, sensitive application data, including encrypted credentials, is stored under a user’s home directory on disk. Critically, the encryption key used to protect these credentials is also stored locally in a configuration file.
By abusing this file read capability, an attacker can retrieve both the encrypted credential data and the key used to protect it, effectively removing the confidentiality barrier.
Vulnerability B: Expression Injection Leading to Remote Code Execution (CVE-2025-68613)
The second vulnerability allows attackers to abuse expression evaluation logic in older versions of n8n. Insufficient isolation between user-defined expressions and the underlying Node.js runtime makes it possible for carefully crafted expressions to escape the intended sandbox and access JavaScript internals.
When executed within an administrative context, this flaw enables arbitrary command execution on the host system, representing the critical impact of the exploit chain.
How the Exploit Chain Works (Conceptually)
1. An attacker leverages the arbitrary file read vulnerability to access sensitive files on disk.
2. The retrieved encryption key is used to decrypt stored credentials.
3. A valid administrative session token is forged using the recovered secrets.
4. With administrative access established, the attacker creates or modifies workflows.
5. Malicious expressions are introduced into workflow logic, resulting in remote code execution.
Each step builds upon the previous one—none are sufficient alone.
Affected Environments and Real-World Conditions
This exploit chain affects locally deployed n8n instances running versions prior to 1.121.0 and requires a specific, non-default configuration: an active workflow that includes a publicly accessible form with a file upload field with authentication disabled for the public form endpoint, and the same workflow must also include a “Respond to Webhook” node that returns uploaded file contents in the HTTP response.
It should be noted that while this configuration is not enabled by default, it reflects a common pattern in automation platforms, where ease of integration and rapid setup are prioritized, particularly for internal tools, one-off workflows, or external data intake scenarios.
Traditional Scanners vs. RidgeBot Detection
Traditional security scanners struggle with exploit chains like this for different reasons. Version-based scanners may flag vulnerable n8n versions regardless of configuration, resulting in false positives even when the required conditions are not met, whereas signature-based scanners can identify the file read vulnerability based on response patterns but lack the ability to validate whether the attack can progress to full compromise. Neither approach can determine whether the entire exploit chain is actually reachable.
In cases like this, partial detection creates uncertainty. RidgeBot’s exploitation-based approach confirms whether a vulnerability is not just present but actually exploitable in its deployed context. For security teams, this means fewer false positives, clear and actionable findings, and evidence that mirrors real attacker behavior without real-world damage.
How RidgeBot Detects the Exploit Safely
RidgeBot takes a different approach by verifying exploitability end-to-end.
- RidgeBot identifies the file read vulnerability by validating the presence of expected response behavior.
- Extracted data is analyzed to determine whether administrative access can be derived.
- RidgeBot forges an administrative session to confirm privilege escalation.
- Controlled, non-destructive commands are executed to verify remote code execution capability.
No malicious actions are performed, and no system state is altered beyond what is required for verification. Any sensitive information observed during detection remains confined to the scanning environment.
Final Thoughts
Attackers rarely rely on single vulnerabilities, they chain small weaknesses into complete compromises. RidgeBot is designed to detect these real-world attack paths by safely validating each step, providing security teams with high-confidence.