n8n webhook path traversal exposes SSH-reachable systems

At a glance

What this is: This is an analysis of an n8n path traversal vulnerability that can turn file uploads into arbitrary file writes and, in chained workflows, persistent access or code execution on SSH-reachable systems.

Why it matters: It matters because workflow automation platforms often hold broad credentials, so a single unsanitized upload can expand from a local file-write bug into a cross-system identity and access failure.

👉 Read Gecko Security's analysis of n8n webhook path traversal and SSH file writes

Context

Path traversal in workflow automation is a governance problem as much as a coding flaw. When an upload field can escape its target directory, the system stops behaving like a bounded file handler and starts behaving like a write primitive against any downstream path the workflow can reach. In n8n's case, that becomes an identity and access issue because the platform often sits on top of SSH credentials, service accounts, and privileged automation paths.

The practical risk is not limited to the vulnerable node itself. Once a workflow can forward attacker-controlled filenames into an SSH upload sink, the security boundary shifts from the web endpoint to every server the automation instance can access. That makes filename validation, path normalization, and credential scoping inseparable controls, which is typical of workflow orchestration platforms with broad integration reach.

Key questions

Q: What breaks when upload filenames are not sanitised in workflow automation?

A: Unsanitised filenames can escape the intended directory and become arbitrary file writes. In workflow automation, that often means an attacker can place files in sensitive locations, overwrite configs, or plant SSH keys and scheduled jobs. The failure is wider than the initial endpoint because downstream nodes may reuse the filename without rechecking it.

Q: Why do workflow automation platforms create outsized access risk?

A: They often concentrate credentials for many connected systems in one place. That means a single flaw can expose API tokens, database access, cloud secrets, and OAuth grants instead of just one application. The risk grows with every integration added to the automation layer, so the architecture matters as much as the vulnerability.

Q: What do security teams get wrong about path traversal in file upload handlers?

A: Teams often treat path traversal as a local input validation issue, but the real risk appears when the filename is consumed by another component. If a later sink concatenates the path, the bug becomes an end-to-end trust failure. Security testing must therefore follow the data flow across nodes, not stop at the first parser.

Q: Who is accountable when automation writes attacker-controlled files to sensitive systems?

A: Accountability sits with the application owner, the platform operator, and the team that scoped the automation credentials. The vulnerability is technical, but the risk is governance-related because credential reach, directory permissions, and workflow design together determine impact. NIST CSF, NIST SP 800-53, and OWASP NHI-style controls are all relevant here.

Technical breakdown

How path traversal turns a filename into a write primitive

The flaw starts when the Webhook node accepts filenames from multipart uploads or Content-Disposition headers without sanitization. If the filename is passed through unchanged, ../ sequences are preserved and can be resolved outside the intended directory. That means the attacker is not just naming a file, but controlling the path resolution outcome. In workflow engines, this is especially dangerous because uploaded content is often treated as trusted binary data once it enters the system. The security defect is therefore a source-side input validation failure, not a storage-layer quirk.

Practical implication: normalize and reject traversal tokens before any filename is stored or forwarded.

Why downstream file sinks amplify the impact

The sink matters because the SSH upload operation concatenates the target directory with the uploaded filename. If the filename already contains traversal segments, the resulting path can escape the intended upload directory and land elsewhere on the remote host. In other words, the sink turns an unsafe filename into an arbitrary write on a reachable system. This is a classic source-to-sink issue: the source preserves attacker control, and the sink consumes it without revalidation. The effect is stronger when automation tools handle infrastructure credentials, because the write lands in a privileged operational context.

Practical implication: revalidate path components at every sink, not only at ingress.

How arbitrary file write becomes persistent access

Arbitrary file write is often the bridge to persistence. Dropping a file such as authorized_keys can grant SSH access, while writing into cron.d or systemd paths can produce scheduled or service-based code execution. The workflow platform does not need to be the final target for the attacker to win. Its value lies in the credentials and network reach it already has. This is why automation platforms should be treated as high-value identity infrastructure: they aggregate access, and a single write primitive can inherit that privilege across many systems.

Practical implication: scope automation credentials so a single workflow cannot write to operationally sensitive locations.

Threat narrative

Attacker objective: The attacker aims to convert a public workflow endpoint into durable access on every server the n8n instance can reach.

1. Entry occurs through an exposed Webhook endpoint that accepts attacker-controlled multipart filenames without sanitization.
2. Credential access follows when the vulnerable workflow forwards the file into an SSH upload operation that uses the supplied filename in path construction.
3. Impact occurs when the attacker writes into sensitive locations such as authorized_keys or cron.d, enabling persistent access or remote code execution.

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

Workflow automation platforms are identity infrastructure when they carry credentials and can reach production systems. This vulnerability is not just a file handling defect. It shows that orchestration tools must be governed like privileged access paths because one workflow can span web input, local storage, and SSH-authorised infrastructure. In practice, the control boundary is the whole automation chain, not the individual node.

Source-to-sink validation is the named concept this breach makes unavoidable. The Webhook node preserved attacker-controlled filenames, and the SSH node consumed them as path inputs. That means the governance failure was not a missing guard at one point, but an absence of end-to-end trust enforcement across the data flow. Teams should treat every transformation stage as a new validation boundary, especially where files cross from web requests into privileged automation.

Standing credentials turn an application flaw into an access-control incident. If the n8n instance can reach deployment servers, backup systems, or databases over SSH, then the blast radius is defined by credential scope, not by the initial endpoint. That is the same governance lesson seen in many NHI incidents: the more broadly a machine identity can act, the more a single input flaw can propagate. Practitioners should narrow what automation identities can touch.

Path traversal in automation should be assessed as a privilege boundary failure, not a pure input bug. Once a file upload can write to arbitrary locations, the issue crosses from application security into PAM, NHI governance, and operational resilience. The organisation needs to know which workflows can write, where they can write, and which identities they do so as. That is the real control question.

What this signals

Automation tooling is increasingly part of the identity plane, not just the application plane. When a workflow engine can write to remote systems over SSH, the organisation needs lifecycle control over the machine identities it uses, the destinations it can reach, and the file paths it is allowed to influence. The control question is whether the automation platform has a narrow enough trust boundary to survive a malformed upload.

Source-to-sink trust collapse: this is the pattern practitioners should watch for in any orchestration or integration stack. The risk is not limited to n8n, because any pipeline that accepts external content and later reuses that content in privileged operations can inherit the same failure mode. For teams building governance around machine identity, the lesson is to bind input validation, credential scope, and sink authorisation together.

For readers mapping this to standards, the useful starting points are the MITRE ATT&CK Enterprise Matrix for credential access and persistence paths, plus NIST SP 800-53 access control and system integrity requirements. The practical signal is simple: if a workflow can move from web input to remote write without a fresh authorisation check, the boundary is too loose.

For practitioners

• Enforce filename canonicalisation at every upload boundary Reject traversal tokens, absolute paths, and encoded path separators before uploaded names are stored, forwarded, or re-used in downstream nodes. Apply the same checks to multipart metadata and Content-Disposition values.
• Revalidate paths before SSH or file-transfer sinks Treat every sink as a fresh trust boundary and compare the resolved destination against an allowlisted directory before writing. Do not rely on earlier sanitisation to remain intact through workflow transformations.
• Constrain automation credentials to narrow write scopes Use SSH identities that can only reach the minimum required hosts and directories, and separate upload workflows from systems that hold persistence-sensitive paths such as authorized_keys, cron.d, or systemd units.
• Audit workflows for file-write to persistence paths Search for any workflow that accepts external files and forwards them into file upload, deployment, or configuration steps. Prioritise those that can reach /etc, ~/.ssh, startup scripts, or CI/CD infrastructure.

Key takeaways

• This vulnerability shows how a single unsanitised filename can turn workflow automation into a remote file-write primitive.
• The impact is amplified by SSH-reachable credentials, which means blast radius is determined by automation scope rather than the original web endpoint.
• The control failure is end-to-end trust enforcement, so teams need path validation, sink rechecks, and tightly scoped machine identities.

Key terms

• Path Traversal: A bug where crafted path segments such as ../ allow input to escape an intended directory boundary. In practice, it turns a normal file operation into a boundary break, which is especially dangerous when the affected service runs with non-human identity privileges and touches production data or secrets.
• Source-to-Sink Trust: Source-to-sink trust describes how untrusted input moves from its point of entry to the operation that actually consumes it. Security breaks when validation happens once at the source but the data is later reused by a different component that assumes it is safe.
• Automation Identity: A non-human identity used by a workflow, script, or orchestration platform to perform actions in other systems. It is not the automation tool itself. The identity needs ownership, scoping, rotation, and retirement because its permissions define the real blast radius.

What's in the full analysis

Gecko Security's full article covers the operational detail this post intentionally leaves for the source:

• The exact vulnerable code paths in the Webhook and SSH nodes, including how the filename is preserved and reused.
• A working proof of concept showing how a malicious upload escapes the target directory and lands on the remote host.
• The affected and patched versions, plus the advisory details needed for change management and remediation planning.
• The impact analysis for n8n Cloud and self-hosted deployments that expose SSH credentials to multiple systems.

👉 Gecko Security's full advisory covers the vulnerable source-to-sink chain, proof of concept, and affected versions.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader access and lifecycle decisions that shape automation risk.