Security alert: two critical vulnerabilities in n8n allow remote code execution and total instance control

A couple of newly discovered safety failures on the N8n workflow automation platform can allow an attacker to take full control of vulnerable instances, obtain confidential data and run arbitrary code on the server hosting the application. Weaknesses, recorded as CVE-2026-1470 and CVE-2026-0863, were discovered by researchers from DevSecOps JFrog and demonstrate, once again, how complex it is to safely isolate dynamic languages within restricted environments.

n8n is an open source tool that makes it easier to channel applications, APIs and services through a visual editor to create automated processes. Its popularity grows every day; for example, the npm package exceeds the 200,000 downloads per week, and its ecosystem supports integrations with artificial intelligence services and language models. This broad adoption makes any failure particularly relevant to companies that depend on internal or Internet-exposed automations.

The first vulnerability, CVE-2026-1470, is a form of sandbox escape in the n8n JavaScript engine. Through inadequate management of the with sentence and insufficient validation of building identifiers, an attacker with the ability to create or modify a flow can cause the sanitizer to solve an identifier to the overall function Function, which opens the door to the execution of arbitrary JavaScript code within the main node of n8n. Although authentication is required to exploit this vector - that is, permission is needed to edit workflows - JFrog stresses that the failure deserves a critical rating (9.9 / 10) because users with moderate privileges, who in many facilities may not be administrators, could climb and control the entire n8n infrastructure. More technical details on this type of evasions can be found in JFrog's report: Achieving Remote Code Execution on n8n via Sandbox Escape.

The second, CVE-2026-0863, affects the Python environment that n8n can invoke as an auxiliary process. In this case, the researchers describe an escape from the sandbox based on the syntactic analysis of the code (AST) that combines introspection through format chains with a particular behavior of Python 3.10 + regarding exceptions and attributes. This combination allows you to recover access to restricted buildings and imports, and finally run operating system commands when Python runs as a subprocess in the main node, which also causes remote code execution at host level.

JFrog's findings put on the table a recurring lesson: containing languages such as JavaScript and Python within safe sandboxes is extraordinarily difficult. Even mechanisms that use lock lists, several layers of validation and transformations on the AST can fail if not all language subtleties and their runtimes are not considered. In the words of the authors of the analysis, performance-time characteristics and behaviour can be used to invalidate security assumptions, so the defence must be as profound and conservative as possible.

n8n launched patches for both vulnerabilities; CVE-2026-1470 was corrected in versions 1.123.17, 2.4.5 and 2.5.1, while CVE-2026-0863 was fixed in 1.123.14, 2.3.5 and 2.4.2. Users operating self-hosted instances should update the above or later versions without delay, as the n8n cloud platform has already applied the corrections and the instances managed by the service are not affected. To check the launch notes and confirm the availability of the patch you can check the official repository: n8n Releases in GitHub.

The researcher Rhoda Smart has published a technical analysis focused on CVE-2026-0863 and has announced that she will add a proof-of-concept in her entry, which often accelerates the search for unparked instances by opportunist attackers. Your technical explanation can be read in: CVE-2026-0863: Python sandbox escape in n8n, and it is a recommended reading for administrators and security teams who want to understand the attack vector and validate it in controlled environments.

These incidents add to previous vulnerabilities that have recently affected n8n; a maximum severity failure called "Ni8mare" allowed remote control of local authorities without authentication, and mass scans initially showed tens of thousands of exposed deployments. Although the number of bodies concerned has been falling, Shadowserver reported about 39,900 instances still accessible at the end of January, reflecting a slow parking rate among many operators.

If you manage n8n in self-hosted mode it is appropriate that, in addition to updating as soon as possible, you review the policies of who can create or modify workflows, according to the network to minimize the impact of a possible commitment, rote credentials and secrets integrated into automations, and monitor logs and unusual activity in the nodes that run external processes. Backup prior to the update and validation of new versions in test environments also helps to avoid operational interruptions.

In short, these vulnerabilities recall that the flexibility of platforms such as n8n is accompanied by an important operational responsibility: maintaining up-to-date infrastructure, applying minimum privilege principles and actively monitoring public exposure are essential measures not to turn a productivity tool into a risk vector for the organization.