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

At a glance

What this is: Pillar Security found a zero-click n8n form RCE that turns a public multi-step form into server-side shell execution and exposes the platform’s stored credential vault.

Why it matters: IAM and NHI teams need to treat public workflow forms, secret storage, and execution contexts as one exposure surface because a form bug can become full credential compromise.

Context

n8n form workflows are meant to be public-facing submission endpoints, but that design assumes user input can be rendered safely back into the page without re-entering an execution path. In this case, that assumption failed because the form pipeline reprocessed user-controlled content after initial substitution, turning a normal contact form into code execution.

For identity teams, the relevance is not the web form alone. n8n stores credentials for connected systems, so a public workflow flaw can become NHI exposure, vault compromise, and downstream access to AWS keys, OAuth tokens, API keys, and database passwords.

The article also shows why self-hosted and cloud deployments need the same governance lens even when the hosting model differs. If the same expression engine and form logic are shared, the trust boundary is shared too.

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 public n8n forms create credential exposure risk for connected systems?

A: Because the workflow engine that renders the form often sits next to the secrets that authenticate the platform to other services. If an attacker reaches code execution, they can pivot from the form into environment variables and stored credentials, which may include keys for cloud services, databases, and SaaS integrations.

Q: What are the signs that an expression engine is failing safely?

A: The safest sign is that user input can be rendered only once and never interpreted again. If a platform supports templates, confirmations, or generated HTML, teams should test whether any submitted value can survive into a second evaluation pass. If it can, the engine is not containing untrusted content correctly.

Q: Should teams prioritize form exposure review or secret rotation first after a workflow RCE?

A: Review exposed forms first so you can cut off the entry path, then rotate secrets if the vulnerable workflow was reachable or if execution occurred. Containment matters before remediation because a public form bug can be a live attack path, while secret rotation limits the blast radius if compromise already happened.

Technical breakdown

How double evaluation turns form input into execution

The core flaw is a double-evaluation path. First, the form engine substitutes the submitted value into the rendered page. Then it scans the resulting HTML again for expression syntax and evaluates anything it finds. That means user input is not just displayed, it is reinterpreted as code after rendering. In secure design terms, the application crosses from presentation into execution without a trust boundary, which is why a harmless-looking confirmation page can become a command runner.

Practical implication: remove any second-pass expression evaluation from user-facing rendering paths.

Why public forms become an attack surface for credential theft

A public multi-step form is dangerous when it can trigger logic in the same workflow engine that stores secrets and credentials. Once the attacker gets code execution, the objective shifts from the form itself to the execution environment and its environment variables, including encryption keys that unlock the credential vault. That is an identity problem because the compromise is not only application code, but also the machine identities and secrets that application controls on behalf of every connected service.

Practical implication: treat public workflow endpoints as potential secret-exposure points, not just input-validation targets.

Why sandbox hardening did not close the gap

The article distinguishes between a runtime sandbox escape and a compiler-stage identifier rewrite failure. Runtime sanitizers can block dangerous builtins after code is prepared, but they do not help if a compiler step leaves unsafe identifiers intact in the first place. That separation matters: a fix at one layer can leave a structurally different bypass alive in another layer. In governance terms, the control failed because the trust model assumed the same protection stage covered both evaluation and compilation.

Practical implication: review compiler-stage and runtime-stage controls separately when assessing expression engines.

Threat narrative

Attacker objective: The attacker aims to achieve server-side code execution and then extract the credential vault to pivot into every connected system.

1. Entry occurs through a public n8n multi-step form that requires no authentication and accepts attacker-controlled input.
2. Credential access follows when the form engine re-evaluates submitted content and permits shell command execution on the server.
3. Escalation occurs as the attacker uses execution context access to reach environment variables and the stored credential vault.
4. Impact is full compromise of the n8n instance and connected systems through decrypted secrets and reused credentials.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Public workflow forms are an identity boundary, not a presentation layer: When a form can trigger execution inside the same platform that stores credentials, the form becomes part of the trust perimeter. That changes the governance question from input handling to execution authority. Practitioners should treat any public workflow renderer as a privileged identity surface, because it can bridge unauthenticated users to stored secrets.

Credential vault exposure is the real blast-radius variable: The immediate bug is a form RCE, but the strategic failure is that one application runtime also holds secrets for many downstream systems. That means a single compromise can inherit AWS keys, OAuth tokens, and API keys without having to break each target separately. The control lesson is that the vault, the renderer, and the execution engine cannot share the same trust assumptions.

Double evaluation is a classic trust-boundary collapse: The same user input was first treated as data and then as executable content. This is not just an implementation flaw, it is a governance assumption that user-supplied values will remain inert after one render pass. The named concept here is render-and-reinterpret exposure: once content is evaluated twice, the application stops knowing where data ends and code begins.

Self-hosting does not change the governance burden: The article notes that both self-hosted and cloud deployments share the same expression engine. That means deployment model is not a substitute for control design, and patch timing alone is not enough if workflows continue to expose public rendering paths. Practitioners should reassess which workflows deserve internet exposure at all.

Expression engines need lifecycle governance, not just patching: This incident illustrates that a vulnerable workflow can remain dangerous even after a narrow bypass is fixed if the underlying rendering model is still unchanged. The broader lesson is to govern form nodes, expression compilers, and secret stores as one lifecycle, because the exploit path spans all three. Identity security teams should map those dependencies before another public workflow becomes a secret exfiltration path.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Identity Guide

What this signals

Render-and-reinterpret exposure: The dangerous boundary is not just the public form, it is the point where user data is reprocessed after being displayed. Teams running workflow automation should inventory any page that echoes user input back into the same engine that handles execution or secret decryption.

The operational signal is simple: if a workflow platform stores credentials and also renders untrusted input, the platform should be treated as a high-value NHI control plane. That is where secret vault design, execution isolation, and public endpoint governance intersect.

n8n, like other workflow systems, becomes a governance problem when its rendering layer and its credential layer are allowed to share assumptions. Public exposure of form endpoints should therefore trigger the same scrutiny you would apply to an externally reachable identity broker.

For practitioners

• Harden public workflow endpoints Remove internet exposure from any form or workflow that renders user input back to the browser unless there is a compelling business case and a compensating control set.
• Separate rendering from execution Block any second-pass expression evaluation in user-facing pages and review template logic for paths that can reinterpret submitted values as code.
• Inventory stored secrets in workflow platforms Treat workflow automation platforms as credential repositories and map every connected account, token, API key, and certificate they can decrypt or invoke.
• Rotate credentials after exposed workflow compromise If a vulnerable instance was internet-facing, rotate the platform encryption key and every downstream secret it could decrypt or proxy.
• Validate compiler and runtime controls separately Test expression engines at both AST transformation and runtime sanitization layers so a bypass in one stage does not survive as a different attack path.

Key takeaways

• A public workflow form can become an execution boundary when user input is evaluated more than once.
• The compromise matters because workflow platforms often hold the credentials that unlock many downstream systems.
• The immediate control issue is not only patching, but removing public rendering paths and rotating any secrets the vulnerable instance could decrypt.

Key terms

• Double Evaluation: A processing flaw where user-controlled content is interpreted more than once, often first as data and then as code. In workflow and template systems, double evaluation creates an execution boundary collapse because content that should remain inert can be re-read as instructions on a later pass.
• Credential Vaulting: Credential vaulting stores privileged secrets in a controlled system rather than distributing them to users or embedding them in workflows. The security value comes from reducing direct exposure, supporting revocation, and creating a single governance point for high-risk credentials.
• Public Workflow Endpoint: An internet-reachable form or automation trigger that accepts input without authentication. In NHI contexts, these endpoints must be treated as high-risk because they can connect unauthenticated users directly to execution logic, secret stores, and downstream service accounts.
• Expression Sandbox: A restricted runtime intended to evaluate formulas or templates without allowing access to dangerous language features. If the sandbox leaves compiler-stage gaps or misses identifier rewrites, an attacker can still reach forbidden builtins and convert a template engine into a code execution path.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.