Critical vulnerabilities in n8n that allow code execution from public forms

Cybersecurity researchers have exposed several critical vulnerabilities in n8n, the workflow automation platform, which have been corrected in the last deliveries of the project. The failures allow from remote command execution to evaluation of expressions without authentication through public forms, and risk both self-managed facilities and cloud deployments.

Two of the most serious failures correspond to the identifiers CVE-2026-27577 and CVE-2026-27493. The first is an isolation break in the expression compiler: a case that was not treated within the abstract syntax tree rewriter allows certain expressions to be executed without the expected security transformation, opening the door to the execution of commands on the server when a user with sufficient permissions creates or modifies a flow. The second takes advantage of the public functioning of the endpoints of n8n forms: a double-evaluation mechanism in the form nodes can allow an attacker to inject malicious expressions without authentication, for example using an exposed contact form.

The combination of both faults can be particularly dangerous: the unauthenticated evaluation of an expression in a public form can be chained with an escape from the expression sandbox to achieve code execution in the host running n8n. Research Pillar Security they showed scenarios in which it was enough to enter a load into the "Name" field of a form to run commands in the affected system.

In addition to these vectors, n8n maintainers have corrected two additional critical vulnerabilities that could also lead to arbitrary code execution: CVE-2026-27495, related to the JavaScript task exchanger sandbox, and CVE-2026-27497, which affects the SQL query mode of the Merge node and allowed to write arbitrary files on the server.

The affected versions cover previous and average branches of the project: versions before 1.123.22, the series 2.0.0 to 2.9.2, and the series 2.10.0 to 2.10.0 inclusive. The patches are available in 1.123.22, 2.9.3 and 2.10.1. Official notices and technical details can be found in the security repositories of the project in GitHub and in the analysis of the discoverers; for more technical context and concrete measures, check the entries to the links of the community itself: the security note of n8n in GitHub and the report of Pillar Security.

The practical risk is high because, in addition to running code, a successful attacker could access the environment variable that n8n uses to cipher credentials ( N8N _ ENCRYPTION _ KEY) and thus decipher tokens, AWS keys, database passwords and other secrets kept in the instance. For this reason, the operation not only allows control of the server, but also the commitment of integrations and services connected from the flows.

If managing the immediate update is not feasible, n8n recommends reducing the exposure surface: restricting who can create and edit flows - limiting these permits to fully trusted personnel -, running n8n in environments with reduced system privileges and strict network controls, and applying specific mitigation on vulnerable nodes. The proposed temporary actions include the exclusion of the form nodes (n8n-no-base.formandn8n-nodes-base.formTrigger) by the environment variable_, the use of the external runner mode (N8N _ RUNNERS _ MODE = external) to narrow the scope of the JavaScript exchanger and the Merge node deactivation if applicable. N8n developers remember that these are provisional solutions and do not replace the installation of official patches.

For operators concerned about the integrity of their environments, in addition to applying the updates, it is advisable to audit the use of form nodes and exposed public routes, rotate keys and secrets if commitment is suspected, review logs and unusual activity and strengthen network segmentation and access policies around the n8n server. The consultation of records and the search for unexpected executions of commands or modifications of workflows are practical steps to detect attempts at exploitation.

Although there are no public reports of mass exploitation in productive environments so far, the severity of the failures and the ease of use in scenarios with public forms make immediate updating the main recommendation. You can read the corrections in the official N8n notices in GitHub and follow the technical analysis in the Pillar Security report to better understand the attack chains and commitment indicators.

Useful links for deepening: explanation and patches in GitHub's advisories on CVE-2026-27577 and CVE-2026-27493, Pillar Security analysis on exploitation via forms Here. and other corrections related to the project security notices: CVE-2026-27495 and CVE-2026-27497. For public vulnerability references, check the corresponding entry in the NIST / NVD inventory when available: https: / / nvd.nist.gov.

In short, the lesson for security administrators and equipment is clear: to systems that allow to run logic or code in running time, the combination of incomplete endpoints and sandboxes is a critical vector. Apply patches, reduce permissions and remove unnecessary nodes are immediate measures that reduce risk while completing a broader response.