RCE risk with Execute Command in n8n
Why the Execute Command node grants full server control and requires extreme caution
What is this issue?
The Execute Command node runs shell commands directly on the n8n server. This is intentionally powerful but extremely dangerous if the command includes any user-controlled input, as it enables Remote Code Execution (RCE).
High-risk usage patterns:
•Commands including user input from webhooks•Dynamic command construction with string concatenation•Executing scripts with user-provided arguments•Shell commands with unsanitized file paths
Why is this dangerous?
Full server access
The command runs with n8n's user permissions, typically accessing all files and network resources.
Command injection
Unsanitized input allows attackers to inject additional commands using ; || && or backticks.
Data exfiltration
Attackers can read any file, dump databases, or send data to external servers.
Persistence
Attackers can create backdoors, modify crontabs, or install malware.
How to fix it
- 1
Avoid user input in commands
Never include user-controlled data in Execute Command nodes. Use alternative approaches.
- 2
Sanitize rigorously
If user input is unavoidable, validate against strict allowlists and escape shell characters.
- 3
Use specific nodes instead
Prefer dedicated nodes (SSH, FTP, S3) over shell commands when possible.
- 4
Restrict permissions
Run n8n with minimal user permissions to limit damage if compromised.
Scan your workflow now
Upload your n8n workflow JSON and detect Execute Command nodes that may have security risks.