TL;DR: A path traversal flaw in n8n's Webhook node lets attackers write files outside the intended directory, and when workflows forward uploads to SSH targets, that can become remote code execution or persistent access on any reachable system, according to Gecko Security. The issue turns workflow automation into an access-path problem, where filename handling and downstream sinks matter as much as workflow logic.
At a glance
What this is: A path traversal flaw in n8n's Webhook node can turn file uploads into arbitrary file writes on remote servers when workflows pass unsanitized names into SSH uploads.
Why it matters: IAM and NHI teams should treat workflow connectors as access pathways, because a single automation flow can convert untrusted input into SSH-level write access and persistence on reachable systems.
Context
A webhook that accepts uploaded files is only safe if it treats every filename and path component as untrusted input. In this case, n8n's Webhook node passed upload metadata into downstream file handling without sanitisation, which created a path traversal condition rather than a simple file-transfer feature.
The governance problem is broader than one bug. When automation platforms hold SSH credentials and move files between untrusted ingress and privileged sinks, they become identity and access brokers in practice. That makes filename validation, path normalisation, and destination scoping part of IAM and NHI control, not just application hygiene.
Key questions
Q: What breaks when webhook uploads are allowed to control SSH file paths?
A: The control that breaks is the boundary between untrusted input and privileged remote writes. If a webhook can pass user-supplied filenames into an SSH upload, path traversal can redirect the write into sensitive directories. That turns a file-transfer workflow into a persistence or execution path, because the remote host is acting on attacker-shaped path data.
Q: Why do workflow automation platforms increase the impact of path traversal bugs?
A: They increase impact because they often sit at the junction of public ingress and privileged internal access. A single parsing flaw in the intake side can reach systems the platform already authenticates to, so the bug becomes an access-path problem rather than a single-server issue. The more hosts the workflow can touch, the larger the blast radius.
Q: What signs show that file-upload logic in a workflow engine is unsafe?
A: Look for file-processing functions that trust request-derived file paths, skip content-type revalidation, or copy files into persistent storage based on mutable request objects. Those patterns indicate that an attacker may be able to steer the engine toward local files instead of uploaded content.
Q: How should teams contain a vulnerable automation connector without breaking operations?
A: Contain it by narrowing the connector's authority, not by relying only on input checks. Fixed destination directories, per-task credentials, and host-level scoping reduce the damage if traversal reappears elsewhere. For this pattern, governance matters as much as patching because the compromise path depends on what the workflow is allowed to reach.
Technical breakdown
How unsanitised upload metadata becomes path traversal
The Webhook node accepts filenames from multipart uploads and Content-Disposition headers, then forwards them into file-handling routines without normalising path separators or stripping traversal sequences. If a filename contains ../, the application no longer stores a simple name. It resolves a relative path escape, which can redirect writes outside the intended directory. That matters because the vulnerable input is not the file contents but the metadata attached to the upload, which often receives less scrutiny than the payload itself.
Practical implication: validate and canonicalise every filename before it reaches storage or downstream file operations.
Why the SSH upload sink turns file write into remote impact
The SSH node concatenates the target directory with the uploaded file name, so the destination path is built from user-controlled metadata plus a privileged transport. When the resolved path escapes the upload directory, the workflow can write anywhere the SSH account can access. In practice, that can mean dropping authorized_keys, overwriting cron entries, or planting services and configs. The security issue is not SSH alone, but the combination of untrusted path construction and a credentialed remote write primitive.
Practical implication: separate trusted destination paths from user-supplied filenames before any SSH upload occurs.
Why automation platforms amplify reach across connected systems
Workflow tools are often trusted with credentials to multiple internal systems, so a single parsing flaw can become a broad access-path problem. A vulnerable webhook endpoint may be externally reachable by design, while the SSH connection behind it is privileged and already allowed to cross network boundaries. That creates a bridge from public input to internal execution surfaces. In identity terms, the platform is acting as a high-trust intermediary, which means its file-handling and credential scope must be governed like an NHI with tightly bounded authority.
Practical implication: inventory which workflows can reach privileged hosts and constrain those credentials to the smallest viable target set.
Threat narrative
Attacker objective: The attacker wants to turn a reachable workflow into arbitrary file write, then use that write access to gain persistent SSH-level control or execute commands on downstream systems.
- Entry occurs when an attacker sends a crafted multipart upload to a reachable n8n Webhook endpoint with a filename containing traversal sequences.
- The filename survives handling and is concatenated into the SSH destination path, allowing the attacker to escape the intended directory on the remote server.
- The attacker writes files into sensitive locations such as authorized_keys or cron directories, creating persistence or command execution on hosts the instance can reach.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- Sumo Logic breach 2023: A compromised credential opened a Sumo Logic AWS account; customers were told to rotate API keys and stored credentials. No data impact was found.
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
Path construction trust is the named failure mode here. The flaw worked because the workflow trusted filename metadata as if it were a safe control input, then reused it in a privileged write path. That is not a generic input-validation issue alone; it is a governance failure over where untrusted identity-adjacent data is allowed to influence access-bearing actions. Practitioners should treat path normalisation as a control boundary, not an implementation detail.
Automation platforms can behave like distributed non-human identities. When a workflow engine holds SSH credentials and moves data between public ingress and internal hosts, it is exercising delegated authority on behalf of the organisation. That makes its file-handling semantics part of NHI governance, because a bad workflow can become a durable access broker. The relevant question is not only whether the webhook is reachable, but what authority the downstream automation can exercise once input crosses the boundary.
Persistent access is the real impact, not just file overwrite. Dropping authorized_keys or cron entries turns a single upload bug into a repeatable foothold that survives the original request. This is why file-write primitives on automation systems deserve the same scrutiny as credential theft: they often create an equivalent outcome through a different route. Practitioners should treat any workflow that can write to remote hosts as a potential persistence path.
Secret-bearing workflow connectors need blast-radius limits. The article shows how one vulnerable flow can reach many servers when the automation layer has broad SSH coverage. That is a NHI governance issue because credential scope, host reachability, and task purpose are all part of the same control plane. Teams should narrow connector authority so a single workflow cannot bridge external input to arbitrary internal host write access.
What this signals
Path traversal in automation is an identity problem when the platform can write on behalf of the organisation. The practical risk is delegated authority crossing from untrusted ingress into credentialed remote access, which is exactly where governance tends to get thin. If a workflow can turn a filename into a remote write, the platform needs the same boundary discipline applied to privileged service accounts and other non-human identities.
Blast radius is determined by connector scope, not just patch status. Once a workflow engine has SSH reach into deployment hosts, backups, or databases, one vulnerable flow can touch far more than its own workspace. The immediate planning question for practitioners is which automations can reach sensitive hosts today, and which of those paths should be reduced before the next similar flaw appears.
For practitioners
- Sanitise upload filenames before any downstream write Canonicalise path input at the webhook boundary, reject traversal sequences such as ../, and preserve only safe base names before storage or transfer.
- Separate destination paths from user-controlled metadata Build SSH upload destinations from fixed server-side paths, not from uploaded filenames, so the file name cannot alter where the remote write lands.
- Restrict workflow SSH credentials to narrow host scopes Limit each automation credential to the smallest set of hosts and directories required for the task, especially where webhooks accept external traffic.
- Review webhook-to-SSH workflows for write primitives Map every workflow that accepts untrusted uploads and identify whether it can write, overwrite, or place files on internal systems reachable by automation.
Key takeaways
- The flaw is not only a path traversal bug. It is a trust-boundary failure that lets upload metadata influence privileged remote writes.
- The impact scales with SSH reach, because automation platforms often hold credentials to many internal systems at once.
- Teams that narrow connector scope and sever filename influence over destination paths can sharply reduce the damage from this class of issue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Unsanitised upload metadata is reused in a privileged write path, exposing credentialed systems to abuse. |
| NHI-05 — Overprivileged NHI | The workflow can write to any host its SSH credentials can reach, which is excessive authority for one flow. | |
| Recommendation — Treat uploaded filenames as untrusted input and block traversal before they can influence privileged writes. Reduce workflow credential scope so each automation path can reach only the hosts it genuinely needs. | ||
| MITRE ATT&CK | TA0006;TA0003;TA0004 — Credential Access; Persistence; Privilege Escalation | The exploit enables persistence and elevated control through file writes into sensitive SSH-accessible locations. |
| Recommendation — Map the write primitive to TA0006, TA0003, and TA0004 and hunt for persistence artifacts on reachable hosts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The workflow's SSH credentials and their scope are central to how the vulnerability becomes impactful. |
| Recommendation — Apply IA-5 to govern credential scope and revoke broad SSH access from automation that does not need it. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is amplified when a workflow can write to internal systems beyond its intended authority. |
| Recommendation — Review entitlements for automation paths and remove write access that exceeds the workflow's task boundary. | ||
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.
- Untrusted Filename Metadata: Untrusted filename metadata is upload information such as original file names or Content-Disposition values that should never be treated as safe instructions. If a workflow uses that metadata in storage or transfer logic, the name itself can alter paths, targets, or overwrite behaviour.
- Remote Write Primitive: A remote write primitive is a capability that lets a user place or modify files on another system through a network service. In identity terms, it matters because the service has effectively expanded the caller's authority beyond normal file permissions and can convert low privilege into execution risk.
- Workflow Blast Radius: Workflow blast radius is the amount of damage a compromised workflow can cause before it is stopped or contained. In identity and security terms, it describes how far a malicious action, bad automation step, or stolen credential can spread across systems, data, and permissions within a process.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a fit for practitioners who need to govern delegated access, service credentials, and automation paths with more discipline.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org