Critical alert: two n8n failures allow remote code execution and could compromise your entire infrastructure

Security researchers have identified two serious failures in the N8n flow automation platform that allow remote code execution in vulnerable instances. The weaknesses were detected by the JFrog research team and, according to the public assessment, one of them reaches an almost maximum severity score, so any unpatched deployment runs a high risk of commitment.

The reported problems are type vulnerabilities oval injection, i.e. vectors that allow dynamic code sent by an authenticated user to be interpreted and executed by the n8n environment. In one case the injection compromises the mechanism that n8n uses to evaluate JavaScript expressions, drawing the sandbox restrictions and allowing to run commands with the context of the main process. In the other, the weakness affects the component in charge of performing tasks in Python (python- task- exector), allowing arbitrary Python instructions to be executed on the underlying system.

The two failures have been recorded in the NIST vulnerability catalogue with the identifiers CVE-2026-1470(with a very high assessment) and CVE-2026-0863. JFrog publishes a detailed technical analysis explaining how sandbox evasion could be done and achieving remote execution; this report is a recommended reading for anyone who wants to understand the attack vector and the operating chain: JFrog analysis.

The potential impact is wide because n8n is used to automate tasks that often connect critical services: from keys and APIs of language models to commercial data and identity management systems. If an attacker is able to execute code in the n8n instance, it can, in practice, obtain transverse access to these automated resources and credentials that are stored or that the platform itself can use, which would multiply the consequences of the incident.

An important factor in this story is the mode of execution of n8n. The official documentation warns that to operate in internal (internal) mode for production environments does not offer the same degree of isolation as separating n8n from the task performer (external mode). When both components share processes or permissions, a vulnerability that manages to escape from the sandbox can reach the main node and, from there, to the rest of the infrastructure. You can see the n8n explanation about the executor settings in your documentation and the description of the system of expressions in pages dedicated to expressions.

These findings also reopen the debate on the difficulty of containing dynamic languages such as JavaScript and Python in restricted environments. Researchers point out that, even with multiple filters and controls based on syntactic analysis or prohibition lists, there are always constructions of the language or behavior of the interpreter that can be used to evade the defenses. In fact, a few weeks ago another maximum-gravity vulnerability in n8n - known as Ni8mare and registered under CVE-2026-21858- showed how easy it can be for a remote attacker to gain full control of an instance, which reinforces the urgency of applying corrections and good practices.

In view of this situation, the immediate recommendation is to apply the versions that correct the failures. For CVE-2026-1470 patches have been published in the branches indicated by the maintainers; the versions containing the correction are 1.123.17, 2.4.5 and 2.5.1. For CVE-2026-0863, the corrected editions are 1.123.14, 2.3.5 and 2.4.2. Updating these versions should be the first mitigation action.

In addition to updating, it is appropriate to review the deployment architecture: to migrate to separate executions between the n8n server and the task runners, to restrict administrative access to the platform, to rotate the credentials and keys stored by n8n and to audit the records in search of suspicious activity. If there is a suspicion that an instance may have been compromised, it is wise to assume that secrets and tokens may be exposed and to proceed with its revocation and renewal.

In sectors where the N8n orchestra chains that include critical services or sensitive data, the exposure of an automation platform is particularly dangerous because it allows automated side movements and access to resources that would normally be out of the reach of an intruder. Therefore, in addition to applying the patches, it is advisable to review security policies, job segregation practices and minimum privileges controls in the integrations it connects n8n.

If you manage n8n instances, check official sources to check available versions and security notes. JFrog's technical report is available on his research blog ( JFrog Research) and details of public identifiers can be found in the NVD database ( CVE-2026-1470, CVE-2026-0863, CVE-2026-21858). It is also useful to review the official n8n documentation on expressions and runners to better understand the operational differences between modes and how to improve isolation: N8n expressions and Task runners configuration.

In short, these vulnerabilities stress that the complexity of the languages interpreted and the desirability of the automation platforms require careful risk management. Updating, isolating processes and reviewing permissions are not just recommendations: in this context, they are essential measures to prevent a tool designed to facilitate work from becoming the gateway for an attack on the entire organization.