N8N Exploited

# N8N CVE-2026-XXXX: How an Unauthenticated File-Read Vulnerability Can Lead to Full Instance Takeover ## Introduction N8N has become one of the most popular workflow automation platforms, allowing organizations to connect applications, APIs, databases, AI services, cloud platforms, and internal systems through automated workflows. But that flexibility also makes security vulnerabilities in an exposed N8N instance potentially extremely dangerous. In a recent security research demonstration, researchers revealed a vulnerability that begins with **unauthorized arbitrary file reading** and can ultimately lead to **administrator access and remote code execution**. The attack chain demonstrates how a seemingly simple file-handling mistake can become a complete compromise when combined with authentication and configuration secrets. > **Important:** The techniques discussed in this article are intended for authorized security research, testing, and defensive purposes. Do not attempt them against systems you do not own or have explicit permission to test. --- ## The Vulnerability at a Glance The researchers discovered a **content-type confusion vulnerability** affecting N8N workflows that use the **Form Webhook** functionality. At a high level, the vulnerability allows an attacker to manipulate an HTTP request so that N8N treats attacker-controlled data as uploaded-file information. Instead of uploading a file from the attacker's computer, the vulnerable workflow can potentially be manipulated into reading a file from the N8N server itself. This creates an important escalation path: **File read → Database extraction → Encryption key extraction → Session forgery → Admin access → Code execution** The researchers demonstrated that this chain can ultimately provide complete control over a vulnerable N8N instance. --- ## Why N8N Is a High-Value Target N8N is commonly used as an automation hub. An enterprise N8N installation may connect to services such as: * Salesforce * Google Drive * SharePoint * Databases * Messaging platforms * CI/CD systems * OpenAI and other AI APIs * Internal applications * Cloud services * Customer databases This means an attacker compromising N8N may gain access to much more than the N8N server itself. Credentials, API keys, tokens, workflow information, and proprietary business data can potentially be accessible through the workflows and integrations configured on the instance. --- ## The Attack Begins With a Form Workflow The demonstrated vulnerability involves N8N's **Form Webhook** functionality. Forms provide an external interface through which users can interact with a workflow. For example, an organization might create a workflow where employees upload documents to an internal knowledge base. A simplified architecture might look like this: **User → Form → N8N Webhook → File Processing → AI/RAG System** This becomes interesting from a security perspective because the form is exposed to user-controlled HTTP requests. The researchers investigated how N8N processes those requests and discovered an inconsistency in the way different content types were handled. --- ## Understanding the Content-Type Problem HTTP requests can contain different types of data. For example, file uploads commonly use: `multipart/form-data` while structured requests may use: `application/json` N8N uses different parsing mechanisms depending on the request's content type. The normal request parser populates request-body data, while the file-upload parser handles uploaded files. The important assumption in the vulnerable code was essentially: > If the application is handling uploaded files, the request must have gone through the multipart file parser. But the researchers discovered that this assumption could be violated. By manipulating the request's content type and body, it was possible to make N8N populate file-related data without following the expected file-upload processing path. This is known as **content-type confusion**. --- ## From Content-Type Confusion to Arbitrary File Read The vulnerable Form Webhook processing code accessed file information without sufficiently verifying that the request had actually been processed as a legitimate multipart file upload. That created an opportunity for attackers to control file-related parameters. The researchers demonstrated that this could be abused to make N8N operate on a file located on the server rather than a file supplied by the attacker. Conceptually, the attack changes from: **"Here is the file I uploaded."** to: **"Here is a reference to a file that already exists on your server."** That distinction is critical. If an attacker can control the path to the file being processed, sensitive files stored on the server may become readable. --- ## Reading Sensitive Application Data The researchers demonstrated the vulnerability against files belonging to the N8N installation. One particularly valuable target was the internal database. The database contained information associated with users, including identifiers, email addresses, and password-related data. The researchers then used the application's knowledge-base workflow to retrieve information from the file that had been loaded. This is an important detail of the attack chain. The vulnerability did not simply display a file directly to the attacker. Instead, the researchers caused the internal file to become available through the application's workflow and then used the workflow's AI/RAG functionality to extract information from it. --- ## Extracting the Encryption Key Reading the database was only part of the attack. The researchers also targeted the N8N configuration. An encryption key stored within the instance's configuration was another critical piece of information. Once the researchers obtained: * The user identifier * The user's email address * Password-related information * The application's encryption key they had the necessary information to construct a valid authentication session. This demonstrates why configuration secrets must be treated as extremely sensitive. A configuration file might look harmless at first, but an application-specific encryption key can become the missing component required to turn a file-read vulnerability into account takeover. --- ## Forging an Authentication Session The next stage of the attack involved creating a forged authentication session. The researchers used the information obtained from the vulnerable instance to generate a session compatible with N8N's authentication mechanism. The process involved JWT signing and other application-specific session logic. Once the forged session was created, the researchers opened an incognito browser window to demonstrate that they were not previously authenticated. They then supplied the forged authentication cookie. After refreshing the page, the browser was authenticated as an administrator. This was the critical escalation: **Unauthenticated attacker → Administrator** No legitimate administrator password was required. --- ## From Administrator Access to Code Execution Administrator access was not the end of the demonstration. The researchers then created a workflow containing an N8N node capable of executing system commands. They demonstrated commands such as checking the current user and listing files on the system. At this point, the attack had progressed to **remote code execution**. The complete chain therefore looked approximately like this: ```text External Workflow Interface ↓ Content-Type Confusion ↓ Arbitrary File Read ↓ Read Internal Database ↓ Read Configuration ↓ Obtain Encryption Key ↓ Forge Authentication Session ↓ Administrator Access ↓ Workflow Command Execution ↓ Full Instance Compromise ``` The important security lesson is that vulnerabilities should not always be evaluated individually. A file-read vulnerability may appear limited. But when the readable files contain authentication information and cryptographic secrets, the impact can become dramatically larger. --- ## Why the Blast Radius Is So Large The researchers emphasized that N8N frequently sits at the center of enterprise automation infrastructure. A single installation can contain credentials for dozens or even hundreds of external services. For example, an organization might connect N8N to: * Salesforce * Google Workspace * SharePoint * Internal databases * Cloud infrastructure * CI/CD pipelines * AI providers * Customer-management platforms * Messaging systems If an attacker gains administrative control over the N8N instance, they may potentially gain access to credentials and data associated with these integrations. The consequences depend heavily on the organization's configuration, but the potential impact can extend far beyond the original N8N server. --- ## The RAG and AI Data Risk The demonstration also highlighted another modern concern: **RAG systems**. Retrieval-Augmented Generation systems allow AI agents to retrieve information from private organizational documents and knowledge bases. If N8N is connected to such a system, compromising the workflow infrastructure can potentially expose: * Internal documents * Company knowledge * Employee information * Product documentation * Customer information * Internal procedures * Proprietary data In other words, the security of an AI workflow is only as strong as the systems surrounding it. An AI agent may be securely configured, but if an attacker compromises the automation platform that provides access to the agent or its data, the information can still be exposed. --- ## How the Researchers Found the Bug The research process is particularly interesting for aspiring security researchers. The researchers began by looking for an **unauthenticated attack surface** in N8N. They identified external interfaces that could be accessed without traditional authentication. One of the important components was the **Webhook** system. Webhooks allow external events to trigger workflows without the application constantly polling another service. A simplified example is: **Polling:** > "Has something happened yet?" > "No." > "Has something happened yet?" > "No." > "Has something happened yet?" > "Yes." A webhook instead tells the service: > "Notify me when this event happens." The service then sends the request when the event occurs. Because webhooks provide external entry points into workflows, they are important areas for security researchers to investigate. --- ## Understanding N8N's Request Processing The researchers examined how webhook requests were processed. There were essentially two important paths. ### Regular Request Processing Normal requests were processed according to their content type, with the resulting information being placed into request-body variables. ### File Upload Processing Multipart file uploads were processed through a file-upload parsing library. The researchers identified a critical assumption: **File-handling functionality expected file information to exist only when the multipart parser had processed the request.** However, another processing path could potentially populate the relevant request structure without actually going through the expected file-upload mechanism. That mismatch created the content-type confusion. --- ## Why Code Review Was Important This vulnerability demonstrates why understanding application source code can be extremely valuable for security research. The researchers did not simply run automated scanners and wait for an alert. They investigated: 1. External attack surfaces 2. Request-processing logic 3. Content-type handling 4. File-upload processing 5. Internal request variables 6. Workflow execution 7. Authentication mechanisms 8. Configuration storage The vulnerability emerged from the interaction between several pieces of functionality. This type of bug can be difficult for traditional vulnerability scanners to identify because the issue depends on how multiple components interact. --- ## Lessons for Security Researchers The researchers also offered advice for people who want to become vulnerability researchers or ethical hackers. ### Learn to Read Code Understanding source code is one of the most valuable skills for application security research. In this case, knowledge of technologies such as: * Node.js * JavaScript * TypeScript * HTTP * Webhooks * File uploads * Authentication * JWT * Application architecture would be highly useful. ### Read Existing Vulnerability Reports Studying previously discovered vulnerabilities can teach you how experienced researchers think. Instead of only reading the CVSS score or a short vulnerability description, study the technical explanation. Ask: * What assumption was incorrect? * What input did the attacker control? * Why did the application trust that input? * What security boundary was crossed? * How was the vulnerability chained with other bugs? ### Develop Curiosity Security research often begins with a simple question: > "What happens if this doesn't work the way the developer expected?" Researchers need to constantly challenge assumptions. ### Be Patient Finding vulnerabilities involves a lot of failure. A researcher may spend days or weeks investigating an idea that ultimately leads nowhere. The ability to continue researching despite repeated failures is one of the most important characteristics of successful vulnerability researchers. ### Join Security Communities Security communities can be valuable sources of knowledge. Researchers can share ideas, ask questions, discuss unusual behavior, and learn from other people's discoveries. --- ## How Organizations Can Protect N8N The most important recommendation from the researchers is straightforward: **Update N8N to a patched version.** If your organization operates an affected N8N installation, upgrading should be treated as a priority. There is also a broader infrastructure-security lesson: ### Don't Expose Services Unnecessarily If an N8N instance does not need to be directly accessible from the public internet, avoid exposing it. Use appropriate controls such as: * VPN access * Network segmentation * Reverse proxies * Access control * Firewall restrictions * Authentication * Monitoring Reducing external exposure can significantly reduce the attack surface. However, network isolation should not be considered a replacement for patching. **The correct approach is to patch the vulnerable software and minimize unnecessary internet exposure.** --- ## The Bigger Security Lesson The most interesting aspect of this vulnerability is not simply that an attacker could read a file. It is how several seemingly separate weaknesses and design assumptions can form a devastating attack chain. A simplified version is: **Input validation weakness** leads to **Content-type confusion** which leads to **Arbitrary file access** which exposes **Authentication and encryption secrets** which enables **Session forgery** which produces **Administrator access** which finally enables **Remote code execution.** This is exactly why modern application security requires more than checking individual functions for obvious vulnerabilities. Attackers think in chains. Security researchers need to do the same. --- ## Conclusion The N8N vulnerability demonstrates how dangerous an unauthenticated file-read issue can become when it exists inside an automation platform containing sensitive credentials, authentication information, configuration secrets, and access to other enterprise systems. The research also provides an excellent example of how modern vulnerability research works. Researchers started with an external attack surface, analyzed the application's source code, identified a content-type confusion issue, demonstrated arbitrary file access, extracted sensitive information, chained the results into authentication bypass, and ultimately achieved code execution. For organizations using N8N, the defensive message is simple: **Keep N8N updated, minimize public exposure, protect credentials and encryption keys, and treat automation platforms as critical infrastructure.** For aspiring security researchers, the lesson is equally important: **Learn how applications work, learn how to read code, study real vulnerability reports, question assumptions, and be prepared to fail repeatedly before finding the bug that matters.** > Security research is often a combination of technical knowledge, curiosity, persistence, and the ability to recognize when two seemingly unrelated behaviors can be chained together.