n8n content-type confusion shows how workflow RCE becomes identity risk

At a glance

What this is: Cyera’s analysis shows that a content-type confusion flaw in n8n can be chained into arbitrary file read, session forgery, and remote code execution across locally deployed instances.

Why it matters: This matters because workflow platforms often sit inside IAM, secrets, and data pipelines, so one flaw can turn non-human access into a broad identity and execution compromise.

By the numbers:

• n8n has over 100 million Docker pulls.

👉 Read Cyera's analysis of n8n CVE-2026-21858 and workflow takeover

Context

Content-type confusion is a parsing flaw where a system trusts the declared request format more than the actual request handling path. In n8n, that mismatch matters because workflow forms and webhook handlers can be used to move files, trigger downstream actions, and bridge untrusted input into privileged automation. For identity teams, the issue is not just application security. It is a reminder that workflow platforms often hold high-value non-human identity material, including credentials, API tokens, and data access paths.

The security gap is structural: when a workflow engine becomes the junction point for human input, service access, and backend execution, one parser mistake can cross multiple trust boundaries at once. That makes the platform relevant to NHI governance, secrets protection, and privileged workflow review, not just code remediation. The failure pattern is typical of automation platforms that assume request shape and execution intent will stay aligned.

Key questions

Q: What breaks when content-type confusion affects workflow file handling?

A: The file upload boundary breaks first, because the system can no longer trust that file metadata came from a real multipart upload. From there, an attacker may control file paths, trigger arbitrary file read, and sometimes reach authentication material or command execution. The core failure is provenance trust, not just bad parsing.

Q: Why do workflow platforms create higher identity risk than ordinary apps?

A: Workflow platforms often sit between users, secrets, and downstream systems, so they accumulate permissions that ordinary apps do not. When one platform stores session data, file paths, and automation credentials together, a single flaw can expose multiple control layers. That makes them a privileged non-human identity surface.

Q: How should security teams decide which workflow nodes need extra review?

A: Any node that handles uploads, copies files, invokes chat interfaces, or executes commands should be reviewed as a privileged access point. These nodes can move data from untrusted input into durable storage or execution. Teams should focus on boundary-crossing nodes first, because they create the widest blast radius.

Q: Who is accountable when a workflow flaw exposes session secrets and code execution?

A: Accountability sits with the team that owns the workflow platform as part of the identity and execution surface, not just the application developer who wrote the form. If the platform can store authentication secrets and launch actions, it falls under privileged access governance and security review.

Technical breakdown

How content-type confusion breaks file upload parsing

The flaw begins when request handling depends on the Content-Type header to choose between parsers. In n8n, multipart requests flow through a file upload parser, while other content types use a regular body parser that can populate req.body fields directly. If a downstream function assumes file data exists only because the user submitted a form, but it never revalidates the content type, the attacker can shape req.body.files through the alternate parser. That turns a simple format mismatch into control over file metadata, including the path used for later file operations.

Practical implication: validate content type at every file-handling boundary, not just at the workflow entry point.

Why req.body.files becomes a path traversal primitive

The dangerous step is not the parser itself, but the way later code trusts req.body.files[id].filepath as if it were a safe temp location returned by the upload library. In the vulnerable flow, prepareFormReturnItem() copies the file from that path into persistent storage. If the attacker controls the object, the code can be redirected to copy local files instead of user uploads. That converts a routine file processing step into arbitrary file read. In workflow systems, this is especially severe because copied content can be handed to later nodes, indexing pipelines, or chat interfaces.

Practical implication: treat file paths in workflow globals as untrusted unless they come directly from a verified upload routine.

How arbitrary file read turns into session forgery and RCE

Once local files are readable, the attack chain can move from data exposure to control-plane takeover. The article shows that local database files and configuration secrets can be extracted, then used to reconstruct the signed n8n-auth session cookie. After authentication bypass, the attacker can create a workflow with command execution capability and reach remote code execution. This is the classic danger of automation platforms: one local file read can expose both identity material and execution authority in the same environment.

Practical implication: separate workflow data storage, authentication secrets, and execution privileges so one read primitive cannot expose all three.

Threat narrative

Attacker objective: The attacker wants to turn a workflow form into a full takeover path that exposes local secrets, bypasses authentication, and grants command execution on the n8n host.

1. Entry occurs when an attacker intercepts a file upload request and changes the declared content type from multipart/form-data to another format so the alternate parser runs.
2. Credential access follows when the attacker controls req.body.files and points the file copy step at local database and configuration files instead of a legitimate upload.
3. Impact is reached when the attacker forges the session cookie, bypasses authentication, and then uses workflow execution features to gain remote code execution.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Workflow automation platforms now sit inside the identity plane, not beside it. The n8n flaw shows that a file upload bug can become an identity event when the platform stores session material, backend secrets, and downstream execution paths in the same trust boundary. That is an NHI governance problem because the compromised object is not only a server process, but the non-human access layer that connects data, tools, and action. Practitioners should treat workflow engines as privileged identity infrastructure, not low-code convenience.

File path trust debt is the named failure mode this breach exposes. The platform assumed that file metadata reaching copy logic still reflected a verified upload path, but that assumption fails once request parsing is attacker-shaped. The result is not merely insecure input handling. It is a broken governance premise that a downstream file operation can safely trust upstream file provenance. Practitioners need to review where workflow systems inherit path values from parse state rather than from verified upload objects.

Centralised automation increases identity blast radius when execution and secrets converge. The article’s n8n example is a clean illustration of why workflow platforms become high-value NHI junctions in modern estates. A single compromise can expose databases, config secrets, and authenticated control over later workflows. That means identity governance for these systems has to account for compounded privilege, not just isolated service accounts. Practitioners should assume the platform is part of their privileged access surface.

OWASP-NHI thinking belongs here because the exploit crosses secret handling, runtime trust, and privileged workflow execution. The issue is not only insecure parsing, but the ability of one weakness to bridge into session material and command execution. That is exactly the kind of chaining NHI governance models are meant to surface. The lesson for practitioners is that workflow platforms need the same review rigor as other privileged non-human access paths.

Identity security programmes should reclassify workflow orchestration as a governed NHI control point. In practice, that means the platform’s forms, webhooks, storage backends, and session secrets are all part of one access system. When those layers are weakly segmented, an application flaw becomes an identity takeover path. The practitioner conclusion is simple: the governance model must match the platform’s effective privilege, not its user-facing simplicity.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
• For a broader control lens, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that reduce exposure windows.

What this signals

File-processing workflows should now be treated as privileged identity infrastructure. The problem is not only whether a parser is correct, but whether the workflow engine can turn untrusted uploads into stored files, stored secrets, and executable actions. Teams should map forms, webhooks, chat triggers, and command nodes into the same control plane they use for other non-human identities.

Workflow engines create identity blast radius when provenance, storage, and execution are co-located. When a single platform can read user input, store files, and touch authentication state, the security boundary collapses into one failure domain. That is why 52 NHI Breaches Analysis remains relevant: privilege concentration, not just weak code, drives the biggest downstream impact.

Programmes that already use NIST SP 800-63 Digital Identity Guidelines for human authentication should not assume the same trust model is safe for workflow automation. The better test is whether a parser bug can cross into secrets, session material, and execution rights before detection or containment.

For practitioners

• Revalidate file intent at every workflow boundary Require each file-handling step to confirm the request is multipart/form-data and that the file object came from a verified upload parser before any copy or transform operation.
• Isolate workflow secrets from file-processing paths Keep database files, signing secrets, and workflow storage separate so a single arbitrary file read cannot expose both authentication material and execution control.
• Review privileged workflow nodes as identity assets Inventory forms, webhooks, chat triggers, and command-execution nodes as high-risk NHI touchpoints, then place them under the same approval and review discipline used for other privileged access.
• Test parser mismatch scenarios in your own workflows Red-team the exact path from uploaded form to downstream file copy using malformed content types, then verify whether any node trusts req.body.files without rechecking provenance.

Key takeaways

• A content-type confusion bug in a workflow engine can become an identity compromise when file paths, session material, and execution controls share the same trust boundary.
• Cyera’s analysis shows the chain can move from arbitrary file read to authentication bypass and then to remote code execution, which makes the blast radius far wider than a typical parsing flaw.
• Teams should govern workflow platforms as privileged non-human identity infrastructure, because one weak file boundary can expose secrets and create command-level access.

Key terms

• Content-Type Confusion: A parsing failure where software trusts the declared request content type more than the actual handling path. In practice, the wrong parser can populate attacker-controlled fields, creating a mismatch between what the application expects and what the request really carries.
• File Provenance Trust: The assumption that a file path or metadata value came from a verified upload process and is therefore safe to reuse. When that assumption is false, downstream copy, indexing, or execution steps can be redirected to attacker-chosen local files.
• Workflow Privilege Surface: The collection of permissions, secrets, and execution rights held by an automation platform. In n8n-like systems, this surface can include file storage, session signing material, database access, and command execution, making the platform a high-value non-human identity control point.

Deepen your knowledge

Content-type confusion, file provenance, and workflow privilege are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around automation platforms and their secrets, it is worth exploring.

This post draws on content published by Cyera: Ni8mare - Unauthenticated Remote Code Execution in n8n (CVE-2026-21858). Read the original.