Zero-click n8n RCE exposes why public forms break NHI trust

At a glance

What this is: Pillar Security’s research shows a zero-click n8n form flaw that can execute shell commands and expose the platform’s stored credentials.

Why it matters: IAM and NHI teams need to treat public workflow endpoints as privileged attack surfaces because one exposed form can become a path into every connected secret and system.

👉 Read Pillar Security's analysis of zero-click n8n RCE and exposed credentials

Context

Zero-click remote code execution in a public workflow form is not a normal application bug. In identity terms, it is a failure of trust at the boundary where unauthenticated input meets a system that also stores credentials for downstream systems.

n8n sits in the middle of many machine-to-machine workflows, so a single compromise can expose AWS keys, database passwords, OAuth tokens, and API keys. That makes the issue relevant to NHI governance, secrets management, and the way teams classify internet-facing automation platforms.

Key questions

Q: What breaks when a public workflow form can re-evaluate user input?

A: A public workflow form stops being a data collection tool and becomes an execution surface. When the same input is rendered twice, user-supplied text can be interpreted as code on the second pass. That creates unauthenticated remote code execution, especially when the form also sits inside a platform that stores credentials for downstream systems.

Q: Why do credential-bearing automation platforms create outsized NHI risk?

A: They concentrate secrets, access tokens, and encryption keys behind a small number of execution paths. If an attacker reaches code execution in the platform, the blast radius extends beyond one workflow to every connected system. That makes exposure management and credential inventory central to NHI governance.

Q: How do teams know if a workflow platform is exposing them to hidden execution risk?

A: Look for public endpoints, multi-step forms, reflected input, and any rendering step that processes user content after substitution. Also review whether the platform can access secrets, environment variables, or shell commands. If those conditions overlap, the workflow design should be treated as high risk until proven otherwise.

Q: Who is accountable when a workflow automation platform exposes stored credentials?

A: Accountability sits with both the platform owner and the team that approved external exposure of the workflow. If the system stores non-human credentials, then identity governance, secrets ownership, and application security all share responsibility for the control failure. This is especially true when public input can trigger server-side execution.

Technical breakdown

Unauthenticated form endpoints and public attack surface

n8n Form nodes create public endpoints by design, which means the attacker does not need an account, a workflow edit path, or prior access. The danger appears when a multi-step form reflects user input back into later rendering steps. In that pattern, the form becomes an execution surface rather than a simple data collection interface. Because the endpoint is reachable over the internet, the attacker can trigger the flaw with nothing more than a browser and a crafted submission.

Practical implication: Treat public form endpoints as externally exposed execution surfaces and inventory every workflow that reflects user input.

Double-evaluation in template rendering

The core bug is double-evaluation. First, user input is inserted into the page template, then the resolved HTML is scanned again for expression syntax and evaluated a second time. That means content that was meant to be displayed as text can be interpreted as code after the first rendering pass. This is a logic flaw in the rendering pipeline, not just a bad filter or a missing validation rule, which is why patching a sanitizer alone does not remove the underlying injection path.

Practical implication: Review any workflow that re-renders user input after substitution and remove secondary evaluation paths wherever they exist.

Sandbox escape and credential vault exposure

The second issue described by Pillar Security is a sandbox escape in the expression compiler. A missing AST rewrite case allowed a dangerous identifier to slip through untransformed, so the runtime safety layer never saw it in protected form. Once execution reached Node.js built-ins, the attacker could run shell commands and access environment variables. In a platform that stores secrets for many connected systems, that turns one execution flaw into credential exposure across the workflow estate.

Practical implication: Assume any runtime escape can become a secrets event and rotate stored credentials whenever a vulnerable instance may have been exposed.

Threat narrative

Attacker objective: The attacker aims to gain shell execution on the n8n server and use that foothold to reach the credential vault and downstream systems.

1. Entry occurred through a public n8n form endpoint that required no authentication and could be reached directly from the internet.
2. Credential access followed when the attacker supplied a payload that survived the first rendering pass and was evaluated during the second pass.
3. Impact was remote command execution on the server, followed by exposure of the platform’s stored credentials and connected systems.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Public workflow forms create identity-adjacent trust without identity controls: A form that accepts internet traffic but also reaches into a credential-bearing automation platform inherits privileged risk without the usual access governance. The article shows that the problem is not just input handling, but the assumption that public submission is separate from execution authority. Practitioners should treat any such form as a governed control point, not a convenience feature.

Double-evaluation is a named failure mode, not a narrow bug class: The flaw works because rendered user content is interpreted twice, first as data and then as code. That is a governance failure in the rendering pipeline, because the system assumes displayed text is inert after the initial pass. The practical conclusion is that teams must classify any secondary evaluation of user input as a boundary breach, not merely a sanitization issue.

Credential vault exposure is the blast radius that matters: n8n stores AWS keys, database passwords, OAuth tokens, API keys, and the encryption key that protects them. Once shell execution is possible, the compromise is no longer limited to one workflow or one form. The field lesson is that automation platforms should be governed like credential concentrators, because the first successful execution path can become an estate-wide secrets incident.

Workflow automation platforms now sit inside the NHI attack surface: This research confirms that public automation endpoints can move from workflow orchestration into direct infrastructure control. That changes how identity teams should classify low-code tooling, because the access model and the credential model are inseparable once execution can be triggered externally. Practitioners should fold public automation systems into NHI oversight, secrets review, and exposure management.

Form rendering logic deserves the same scrutiny as secret storage: The exploit chain proves that a front-end confirmation page can be the entry point to back-end compromise. That is why the named concept here is double-evaluation execution debt: a design that leaves user input available for re-interpretation after initial rendering. Teams should assume any such pipeline can convert benign-looking input into server-side execution.

From our research:

• 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• From our research: 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.

What this signals

Double-evaluation execution debt: Any workflow engine that renders user input more than once creates a latent execution boundary problem. For IAM and NHI teams, that means public forms, low-code automations, and credential-heavy integrations need exposure review as often as they need patching.

The operational signal is not just the CVE. It is whether the organisation can map which workflows have internet exposure, what secrets they can reach, and whether a compromise would cascade into broader system access.

Teams should expect public automation surfaces to be folded into broader NHI and agent governance programmes, especially where the same platform brokers credentials, external APIs, and runtime actions.

For practitioners

• Inventory every public form workflow Identify all internet-facing n8n form endpoints, especially multi-step forms that reflect user input back to the submitter. Prioritise anything that renders confirmation pages, greetings, summaries, or submission receipts because those are the patterns most likely to create a second evaluation path.
• Patch affected instances immediately Move self-hosted deployments to n8n 2.10.1, 2.9.3, or 1.123.22 depending on the release channel. Treat cloud and self-hosted environments differently in operations, but not in exposure assumptions, because both rely on the same underlying expression engine.
• Rotate stored credentials after exposure If an affected instance was reachable during the vulnerable period, rotate every stored secret, including AWS keys, database passwords, OAuth tokens, API keys, and the encryption key used to protect them. Assume the instance acted as a credential vault and not just a workflow runner.
• Remove secondary evaluation from form rendering Audit workflow logic for any pattern where input is rendered once and then re-processed for expressions, templates, or embedded code. The safest pattern is single-pass rendering with no re-evaluation of user-supplied content after substitution.
• Bring automation platforms into NHI governance Add workflow engines that store or broker credentials to the same review, logging, and exposure-management processes you use for other non-human identities. If a public endpoint can trigger execution, the platform is part of the identity perimeter, not just the application stack.

Key takeaways

• A public workflow form can become an unauthenticated execution path when user input is re-evaluated after rendering.
• The practical impact is broader than one server, because credential-bearing automation platforms concentrate access to many downstream systems.
• The control that matters most here is eliminating secondary evaluation and treating exposed workflow engines as part of the identity perimeter.

Key terms

• Double-Evaluation Execution Debt: A design flaw where user-supplied content is rendered once as data and then processed again as code or expressions. In practice, this creates a hidden execution boundary because apparently harmless text can become active instructions after substitution. It is especially dangerous in workflow systems that mix public input with server-side templating.
• Credential-Bearing Automation Platform: A workflow or integration platform that stores credentials for multiple downstream systems and can use them during runtime. These platforms are operationally useful, but they also concentrate risk because one compromise can expose many secrets at once. They should be governed as identity infrastructure, not as simple application plumbing.
• Public Execution Surface: An internet-reachable endpoint that can trigger server-side logic, data access, or command execution without prior authentication. Public execution surfaces are high-risk because the attacker does not need an account to reach the dangerous code path. In identity terms, they require the same scrutiny as privileged access points.

Deepen your knowledge

Zero-click workflow exploitation and credential-bearing automation platforms are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team runs public forms or low-code workflows, it is worth understanding how identity governance changes when execution and secrets live in the same platform.

This post draws on content published by Pillar Security: Zero Click Unauthenticated RCE in n8n, a contact form that executes shell commands. Read the original.