Notifications
Clear all
Topic starter
02/08/2026 12:02 pm
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.
NHIMG editorial — based on content published by Gecko Security: n8n webhook path traversal advisory
Questions worth separating out
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.
Q: Why do workflow automation platforms create outsized access risk?
A: They often concentrate credentials for many connected systems in one place.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Gecko Security's analysis of n8n webhook path traversal and SSH file writes →
n8n webhook path traversal: what it means for SSH-reachable access?
Explore further
02/08/2026 1:08 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: n8n webhook path traversal exposes SSH-reachable systems
