The automation world got a wake-up call this January when n8n, a popular workflow automation tool, disclosed a serious security flaw affecting thousands of self-hosted instances worldwide. While the vulnerability was quietly patched back in November 2025, the public announcement on January 8th has sparked important conversations about workflow security and responsible disclosure practices.
![n8nv]()
Understanding the Vulnerability
At its core, this security issue stems from improper input validation in n8n's form handling mechanism. The problem specifically targets workflows that combine two seemingly innocent components: a Form Submission trigger and a Form Ending node that returns binary files. When these elements work together in versions 1.65 through 1.120.4, they create an unexpected security gap.
Think of it like leaving a window slightly ajar in your house. It looks closed from the outside, but someone who knows exactly where to look could potentially squeeze through. In technical terms, an attacker who could access the form—even without any authentication—might exploit this weakness to read files from the underlying system. This isn't just about accessing workflow data; depending on how the instance was configured, it could open doors to much more sensitive information.
The vulnerability falls into a category that security professionals call "path traversal" or "directory traversal" attacks. Essentially, the flaw allowed attackers to manipulate file paths in ways the developers never intended, potentially navigating beyond the restricted directories where they should have been confined[1].
The Timeline: Why the Delay in Disclosure?
One question many in the community have been asking is why n8n waited nearly two months between fixing the issue (November 18, 2025) and publicly announcing it (January 8, 2026). The company's reasoning actually follows established security industry practices known as "responsible disclosure."
Here's the logic: when you discover a critical vulnerability, immediately shouting it from the rooftops before users can protect themselves is like posting the combination to a safe while thieves are listening. n8n wanted to give their cloud customers time to update automatically and self-hosted users the opportunity to patch their systems before malicious actors learned about the exploit and began scanning for vulnerable instances[1].
This approach has its critics and supporters. Some argue that transparency should always come first, while others point out that real-world security often requires balancing openness with pragmatism. The two-month window gave the vast majority of users time to update without the pressure of active exploitation attempts.
Who's Actually at Risk?
Not every n8n user needs to panic. The vulnerability specifically affects self-hosted instances running versions between 1.65 and 1.120.4. If you're using n8n Cloud, the platform's managed service, your instance was automatically upgraded on November 18th—no action required on your part[1].
For self-hosted users, there's a silver lining: the vulnerability only becomes exploitable under specific conditions. Your instance is only at risk if you've created an active workflow containing both a Form Submission trigger and a Form Ending node that returns binary files. It's worth noting that n8n has even released a workflow template that scans your instance to identify potentially vulnerable configurations[2].
Anyone running version 2.x of n8n can breathe easy—these newer versions were built with the security fix already baked in[1].
The Potential Consequences
If this vulnerability were successfully exploited, the consequences could range from concerning to severe depending on your specific setup. In the most direct scenario, an attacker could gain unauthorized read access to files on your system. This might include workflow configurations, stored credentials, or other sensitive data that your n8n instance can access[1].
In certain deployment configurations, the situation could escalate further. The vulnerability might enable privilege escalation, allowing an attacker to perform actions they shouldn't have permission to execute. Given that workflow automation tools often have access to multiple connected services and APIs, a compromised n8n instance could potentially serve as a stepping stone to broader network infiltration.
The real-world impact would heavily depend on factors like what data your workflows handle, how your n8n instance is networked, and what permissions it operates under. An instance that automates data transfers between customer databases would pose a much higher risk than one that simply sends notification emails.
The Positives: What n8n Got Right
Despite the severity of this vulnerability, there are several encouraging takeaways from how n8n handled the situation:
Proactive Security Posture: n8n maintains a Vulnerability Disclosure Program, actively encouraging security researchers to report issues. This is far better than companies that try to hide problems or discourage researchers from looking for them[1][4].
Swift Response: Once notified in November, the team acted quickly to develop, test, and deploy a fix. Cloud customers were protected within days, not weeks or months.
Transparent Communication: While the delay in public disclosure is debatable, n8n ultimately came forward with clear information about what happened, who was affected, and what users needed to do. They didn't try to downplay the severity or hide behind vague language[1].
Practical Tools: By releasing a workflow template to scan for vulnerable configurations, n8n gave users an easy way to assess their risk without requiring deep technical knowledge[2].
Learning Opportunity: This incident highlights the importance of input validation in web applications, a lesson that benefits the entire development community.
The Concerns: Where Things Could Improve
No security incident is without its lessons, and this one raises several important questions:
The Disclosure Delay: While n8n's reasoning makes sense from a security perspective, two months is a long time in the world of cybersecurity. Some users might feel they had a right to know sooner, especially since the vulnerability affected versions dating back months or even years before the fix.
Version Coverage: The fact that this vulnerability existed across such a wide range of versions (1.65-1.120.4) suggests it might have been present in the codebase for a considerable time. This raises questions about security auditing practices during that period.
Dependency on User Action: Self-hosted users need to manually update their instances, and history shows that many users delay updates or don't apply them at all. The longer vulnerable instances remain active, the higher the risk.
Limited Attack Surface Context: While n8n provided good information about the technical nature of the vulnerability, more details about real-world exploitability would help users better assess their risk. How difficult would this attack be to execute? Are there compensating controls that reduce risk?
Comprehensive Solution and Remediation Steps
If you're running an affected version of n8n, here's exactly what you need to do to secure your instance:
Immediate Action Required
Step 1: Check Your Version First, determine which version of n8n you're currently running. You can typically find this in your n8n dashboard or by checking your installation directory.
Step 2: Update to a Secure Version If you're running version 1.65-1.120.4, you need to upgrade immediately to version 1.121.0 or later. The update process varies depending on your installation method:
For Docker installations:
docker pull n8nio/n8n:latest
docker stop n8n
docker rm n8n
# Restart with your usual docker run command
For npm installations:
npm update -g n8n
For self-hosted deployments with custom configurations, consult the n8n documentation for version-specific upgrade instructions[3].
Step 3: Scan Your Workflows Even after updating, run the vulnerability scanner workflow template that n8n has provided. This will identify any workflows in your instance that matched the vulnerable pattern, helping you understand if you were potentially at risk[2].
Step 4: Review Your Workflow Security Take this opportunity to audit all workflows that use Form Submission triggers:
Review who has access to these forms
Consider implementing authentication for sensitive forms
Evaluate whether binary file returns are necessary in your form endings
Document which workflows handle sensitive data
Additional Security Hardening Measures
Beyond the immediate patch, consider these supplementary security measures:
Implement Network Segmentation: Place your n8n instance behind a firewall or VPN, restricting access to only necessary networks and users.
Enable Logging and Monitoring: Configure comprehensive logging for your n8n instance to detect unusual activity. Monitor for unexpected file access patterns or authentication attempts.
Apply Principle of Least Privilege: Ensure your n8n instance runs with minimal system permissions. It should only have access to directories and resources it absolutely needs.
Regular Security Audits: Schedule quarterly reviews of your n8n workflows, checking for security best practices and potential vulnerabilities.
Backup Strategy: Maintain regular backups of your n8n configuration and workflows, stored separately from your production instance.
Access Control Review: Audit who has administrative access to your n8n instance and implement multi-factor authentication where possible.
For Organizations with Multiple Instances
If you manage multiple n8n installations across your organization:
Create an inventory of all n8n instances, including version numbers and update status
Prioritize updates based on exposure (internet-facing instances should be updated first)
Implement a centralized update policy to prevent similar delays in the future
Subscribe to n8n's security advisories to receive immediate notification of future vulnerabilities[3][4]
Consider implementing automated vulnerability scanning as part of your DevSecOps pipeline
Long-Term Prevention Strategies
To avoid similar vulnerabilities in the future:
Stay Current: Establish a policy of updating to the latest stable version within 30 days of release. Security patches should be applied within 48-72 hours of disclosure.
Test in Staging: Before applying updates to production, test them in a staging environment that mirrors your production setup.
Input Validation Review: If you develop custom integrations or nodes for n8n, ensure all user inputs are properly validated and sanitized.
Security Training: Ensure team members who create workflows understand basic security principles, particularly around handling external inputs and file operations.
What This Means for the Automation Community
This incident serves as an important reminder that workflow automation platforms, while incredibly powerful, are also potential security chokepoints. These tools often have extensive access to various systems and data sources, making them attractive targets for attackers.
Organizations using any automation platform—not just n8n—should consider several security best practices:
First, maintain a rigorous update schedule. Security patches only protect you if you actually apply them. Consider automating update processes where possible, or at minimum, subscribe to security advisories from all your vendors.
Second, implement the principle of least privilege. Your automation workflows should run with only the minimum permissions necessary to accomplish their tasks. This limits potential damage if a vulnerability is exploited.
Third, audit your workflows regularly. Review what data they access, what external services they connect to, and who can trigger them. The workflow scanning template n8n provided is a good example of the kind of security hygiene that should be routine.
Finally, if you're running self-hosted infrastructure, ensure you have proper monitoring in place. Unusual file access patterns or unexpected network connections might be early indicators of exploitation attempts.
The Bigger Picture
Security vulnerabilities are an inevitable part of modern software development. What matters isn't whether they exist—they always will—but how companies and communities respond when they're discovered. n8n's handling of this situation shows both the progress we've made in security practices and the challenges that remain.
The responsible disclosure approach, while imperfect, represents a mature understanding that security is about more than just transparency—it's about timing, context, and giving people the tools they need to protect themselves. At the same time, the two-month delay pushes the boundaries of what many would consider reasonable.
For users of n8n specifically, the immediate action is clear: if you're running a self-hosted instance on a version between 1.65 and 1.120.4, update to version 1.121.0 or later as soon as possible. Run the vulnerability scanner to identify at-risk workflows, and consider this an opportunity to review your broader security practices.
For the wider technology community, this incident reinforces lessons we keep learning: input validation matters, security is an ongoing process rather than a destination, and the tools we use to make our work more efficient can also introduce new risks that require careful management.
The good news is that this vulnerability was found, reported responsibly, and patched before widespread exploitation occurred. Not every security story ends that way. While there's always room for improvement in disclosure practices and preventive measures, the outcome here represents security working more or less as it should—even if the process felt uncomfortably long for those waiting for public information.
As we continue to build increasingly interconnected and automated systems, stories like this one will become more common. Our collective response—as developers, users, and security professionals—will determine whether we're prepared for the challenges ahead.
References
[1] n8n Team. (2026, January 8). "Security Advisory: Security Vulnerability in n8n Versions 1.65-1.120.4." n8n Official Blog. https://n8n.io/blog/security-advisory-january-2026/
[2] n8n. (2026). "Vulnerability Scanner Workflow Template." n8n Community. Available through n8n workflow templates library.
[3] n8n Documentation. (2026). "Release Notes and Security Updates." https://docs.n8n.io/release-notes/
[4] n8n Security. (2026). "n8n CVE Disclosures." GitHub Security Advisories. https://github.com/n8n-io/n8n/security/advisories