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.
Editorial analysis by NHI Mgmt Group, based on content published by Gecko Security: “CVE-2026-25055: n8n Arbitrary File Write on Remote Systems via SSH Node”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The flaw is not only a path traversal bug. It is a trust-boundary failure that lets upload metadata influence privileged remote writes.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:08 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: n8n webhook path traversal exposes SSH-reachable systems