Critical Chain of Vulnerabilities in n8n: From Prototype Pollution to Full Remote Code Execution

A sophisticated chain of security flaws has been identified within n8n, the widely adopted low-code workflow automation platform. Security researchers have demonstrated that by orchestrating multiple vulnerabilities, a relatively low-privileged attacker can escalate their access to achieve full Remote Code Execution (RCE) on the host infrastructure. This discovery underscores the inherent risks in automation engines that process highly dynamic, user-defined data.

The vulnerabilities, detailed through several GitHub Security Advisories, impact all versions prior to 1.123.43, 2.20.7, and 2.22.1. While an attacker must possess authenticated access to trigger these flaws, the “low-privilege” requirement is a significant concern; in many enterprise deployments, any user with permission to create or modify workflows could potentially serve as an entry point for a full system takeover.

Technical Breakdown of the Vulnerabilities

1. Prototype Pollution via HTTP Request Node (CVE-2026-44789)

The most potent vector in this chain is CVE-2026-44789. This flaw resides within the HTTP Request node and is rooted in the improper validation of pagination parameters. By sending specifically crafted payloads, an attacker can trigger Prototype Pollution—a vulnerability where the global {@code Object.prototype} in JavaScript is modified.

In the context of n8n, this isn’t just a theoretical bug; it allows an attacker to inject properties into the base object that the application relies on for logic execution. By polluting these prototypes, an attacker can alter the behavior of the entire runtime environment, effectively laying the groundwork for arbitrary code execution when paired with other logic flaws.

2. Argument Injection in Git Node (CVE-2026-44790)

A second critical vector, CVE-2026-44790, targets the Git node. This is a classic case of CWE-88 (Improper Neutralization of Special Elements used in an OS Command). When the node performs a ‘push’ operation, it fails to adequately sanitize command-line arguments.

An attacker can inject malicious flags into the Git command, enabling arbitrary file reads. This allows for the exfiltration of highly sensitive data residing on the server, including environment variables, `.env` files, SSH keys, and cloud provider credentials, which can then be used to pivot deeper into the organization’s network.

3. XML Node Patch Bypass (CVE-2026-44791)

Finally, researchers identified a regression/bypass in the XML node, documented as CVE-2026-44791. Despite previous attempts to patch prototype pollution within the XML processing logic, a bypass was discovered that allows attackers to circumvent these protections. This flaw serves as a critical “reinforcement” for the RCE chain, providing an alternative path to manipulate object prototypes through XML parsing.

These vulnerabilities collectively represent a high-impact threat. The combination of network-based attack vectors, low privilege requirements, and the lack of required user interaction makes this a “perfect storm” for automated exploitation.

Remediation and Defense

The n8n team has responded swiftly by releasing patched versions. Immediate upgrades are the only definitive solution. Ensure your instance is running one of the following (or newer):

  • Version 1.123.43+
  • Version 2.20.7+
  • Version 2.22.1+

If an immediate upgrade is not feasible due to deployment constraints, consider the following mitigation strategies as temporary stop-gaps:

  • Principle of Least Privilege: Audit your n8n user roles. Restrict the ability to create or edit workflows to only highly trusted, vetted administrators.
  • Node Restriction: Use the NODES_EXCLUDE environment variable to disable the HTTP Request, Git, and XML nodes across your installation. This will break workflows relying on these nodes but will effectively neutralize the primary attack vectors.

In a DevOps-centric environment, these flaws highlight a critical reality: automation platforms are often treated as “internal tools” and granted excessive trust. An attacker who gains access to a single junior developer’s credentials could, through these flaws, transform a simple workflow into a weaponized script that extracts every secret in your infrastructure. Treat your automation engine with the same security rigor as your production database.

Related Articles

Back to top button