GHSA-9x83-43r8-5hwcn8nSandbox EscapeRCE

GHSA-9x83: when editing an n8n workflow becomes code execution on the host

Permission to build a workflow appeared confined to the editor. A live reference to a host prototype crossed the sandbox and reached the main n8n process.

By Equipe VorvexPublished on August 23, 20265 min read

On an automation platform, granting someone permission to edit workflows should not be equivalent to handing them a shell on the server. Advisory GHSA-9x83-43r8-5hwc exposed exactly that broken boundary in n8n: an expression created by a user with workflow-building privileges could escape the evaluation environment and compile code inside the main process. The potential result is full compromise of the instance that concentrates credentials, webhooks, and connections to other systems.

Technical diagram of an n8n workflow editor inside a sandbox boundary, with a prototype chain crossing the boundary into the main host process and reaching credential vaults and connected business systems. — The expected boundary ended at the sandbox. The prototype chain created a bridge to the main process and everything it could reach.

What the advisory confirms

The maintainer published the GHSA on August 19, 2026, with high severity and a CVSS 4.0 score of 8.7. The official vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: network attack, low complexity, no additional requirements, low privileges, and no interaction from another person. As of this article, the advisory does not associate a CVE with the issue, so we use the GHSA identifier instead of creating a reference that does not exist.

The 1.x line is fixed in 1.123.73.
The stable 2.35 line is fixed in 2.35.4.
The beta 2.36 line is fixed in 2.36.2.
n8n Cloud instances were patched automatically, according to the vendor bulletin.
Self-hosted instances below the fix for their release line must be upgraded by the operator.

How an inherited property crossed the sandbox

The root cause lies in a small JavaScript distinction with a large effect at security boundaries. When resolving a caller-supplied placeholder name, `$fromAI` did not require the key to be an own property of the object and also admitted reserved keys. In JavaScript, looking up a key without that check can continue through the prototype chain. Against a primitive value, that resolution returned a live reference to a prototype from the host environment.

From that reference, an expression could walk to the `Function` constructor. That constructor compiles JavaScript code, and the code no longer ran inside the restricted model expected for the expression. The decisive point is not merely obtaining an unexpected object. It is obtaining an object that still belongs to the host process and retains a path to an execution capability.

Accepting user-controlled property names expands the input far beyond the intended fields.
Blocking a few dangerous names is insufficient if resolution still traverses inherited properties.
Copying data into prototype-free structures and requiring own properties reduces this class of confusion.
Objects that cross the sandbox boundary must not retain live references to host constructors or prototypes.
Security tests need to cover reserved keys, primitive values, and prototype paths, not only ordinary expressions.

Why low privilege still means high impact

The prerequisite is an authenticated account capable of building or editing workflows. This narrows the attacker population, but it does not reduce what happens after the escape. Code runs in the main n8n process and inherits the service account's permissions, network access, and available files. In many deployments, that process must reach databases, queues, internal APIs, and external services for automation to work.

Blast radius diagram showing a compromised n8n main process at the center with access paths to stored credentials, internal APIs, databases, queues, SaaS platforms, and outbound webhooks. — The blast radius does not end at the container. It follows the credentials, routes, and integrations granted to the automation process.

This is why permission to edit workflows should be treated as development privilege over a sensitive system, not ordinary business access. n8n documentation notes that editors can execute workflows and use credentials already attached to them, even when the credential was not directly shared. The flaw added a route out of that controlled delegation and into the environment holding the integrations.

Upgrade and confirm the runtime

The fix is to upgrade to 1.123.73, 2.35.4, 2.36.2, or a later version within the adopted release line. In a self-hosted deployment, changing a tag in the repository or completing the pipeline is not enough. Confirm the version of the running container, align components such as workers and runners, and verify that old replicas are no longer serving traffic.

bash

# Exemplo para uma implantacao Docker Compose cujo servico se chama n8n
docker compose pull n8n
docker compose up -d n8n
docker compose exec n8n n8n --version

# Auditoria defensiva documentada pelo n8n
docker compose exec n8n n8n audit

Upgrade, confirmation of the version actually running, and a defensive audit. Adjust the service name to your Compose file and preserve the output as change evidence.

The `n8n audit` command does not prove exploitation and does not replace an investigation. It helps locate risks that increase impact, including nodes with filesystem access, official high-risk nodes, community nodes, unprotected webhooks, missing security settings, and an outdated instance. Use its output to reassess the blast radius after patching.

If the patch cannot be deployed now

The advisory is clear that temporary controls do not remediate the vulnerability. Until the upgrade, restrict the instance to fully trusted users, disable AI-related nodes and features when they are not required, and run the process under a dedicated low-privilege system account. It is also worth removing direct internet access, limiting outbound network paths, and reviewing which projects truly need editors.

Temporarily remove workflow-editing capability from accounts that do not need it.
Disable unused AI features and record the exception with an expiration date.
Separate credentials by project and reduce scopes in the destination service, not only in n8n.
Run n8n as an unprivileged user, with filesystem and network access limited to what is necessary.
Review authentication logs, workflow changes, unusual executions, and outbound connections for the period before patching.
Rotate secrets if there is evidence of unauthorized execution or if telemetry cannot rule out that possibility.

What a pentest should validate beyond the version

A scanner identifies the vulnerable version. A contextual pentest must test the trust model that made the impact so high: who receives the editor role, which credentials are available by project, which nodes allow code or file access, what destinations the process can reach, and whether anomalous execution appears in telemetry. The useful question is not only whether the GHSA was fixed, but whether another editor flaw would find the same open path to production.

Map global roles, projects, sharing, and accounts with no recent use.
Validate isolation between projects and indirect credential use in shared workflows.
Inventory code, filesystem, Git, shell, community, and AI tool nodes.
Test outbound controls for databases, internal APIs, metadata endpoints, and cloud services.
Confirm that sensitive changes, executions, and secret access produce useful logs and actionable alerts.
Retest with an authorized low-privilege account without running a destructive payload in production.

The lesson from GHSA-9x83-43r8-5hwc is bigger than one bug in `$fromAI`. Automation platforms bring configurable code, identity, secrets, and connectivity into the same plane. When a sandbox fails, all of those capabilities define the impact. Fixing the version closes this route. Reducing privilege and reach limits the next one.

← Back to blog