CVE-2026-86079 in n8n
Summary
by MITRE • 09/09/2026
n8n is an open source workflow automation platform. Prior to 1.123.76, 2.37.7, and 2.38.2, the Elasticsearch and ElasticSecurity nodes interpolated workflow-controlled index and document identifiers directly into REST request paths. An identifier containing path separators or dot segments could select another index or a cluster administration endpoint under the stored Elasticsearch credential. The affected request construction includes packages/nodes-base/nodes/Elastic/Elasticsearch/GenericFunctions.ts and the missing toPathSegment encoding. This issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in n8n prior to versions 1.123.76, 2.37.7, and 2.38.2 represents a critical server-side request forgery risk stemming from improper input validation within the Elasticsearch and ElasticSecurity integration nodes. As an open-source workflow automation platform, n8n allows users to construct complex workflows that interact with various external services. In this specific instance, the flaw resides in how these nodes handle dynamic identifiers for index names and document IDs. The underlying code, specifically located in packages/nodes-base/nodes/Elastic/Elasticsearch/GenericFunctions.ts, failed to properly encode or sanitize user-controlled input before appending it directly into REST API request paths. This lack of encoding means that any string provided by the workflow author as an identifier is treated literally by the HTTP client without checking for malicious structural elements such as path separators or dot segments.
From a technical perspective, this flaw enables an attacker who can control the inputs to these nodes to manipulate the target URL structure. By injecting characters like forward slashes or sequences representing parent directory traversal, such as double dots, an adversary could redirect the request away from the intended Elasticsearch index or document endpoint. Instead of interacting with the specific data store configured in the workflow, the maliciously crafted identifier allows the selection of arbitrary indices within the same cluster or even access to sensitive cluster administration endpoints. This behavior is characteristic of CWE-20 Improper Input Validation and CWE-749 Exposed Dangerous API Method, as it bypasses intended restrictions on resource access by exploiting how HTTP clients parse URL paths. The absence of proper path segment encoding creates a direct vector for unauthorized data access or configuration manipulation within the Elasticsearch environment associated with the compromised credentials stored in n8n.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and data exfiltration. Since n8n workflows often run with elevated privileges defined by the stored Elasticsearch credentials, an attacker exploiting this flaw could read sensitive documents from unintended indices that were not meant to be accessible via the workflow logic. Furthermore, if the cluster exposes administrative APIs through standard REST paths, the attacker might execute commands that alter index mappings, delete data, or compromise the integrity of the search infrastructure. This aligns with ATT&CK technique T1078 Valid Accounts, as it leverages legitimate credentials to access unauthorized resources by manipulating request parameters rather than breaking authentication mechanisms directly. The risk is compounded in multi-tenant environments where different workflows might share underlying Elasticsearch clusters but expect strict isolation between their respective data scopes.
Mitigation for this vulnerability requires immediate upgrading of the n8n installation to version 1.123.76, 2.37.7, or 2.38.2, which includes patches that enforce proper encoding of path segments in REST requests. Organizations relying on these versions should also review their workflow configurations for any nodes accepting user-supplied index names or document IDs and ensure that input validation is applied at the application level where possible. Additionally, implementing network-level controls such as firewall rules to restrict access to Elasticsearch administrative endpoints can provide a layer of defense-in-depth against exploitation attempts. Regular security audits of automation workflows are recommended to identify similar patterns of unsafe request construction in other integrations supported by the platform.