n8n patches path injection in its Elasticsearch nodes

The workflow automation vendor n8n has patched a path injection flaw in its Elasticsearch and ElasticSecurity nodes, disclosed in a GitHub security advisory published on 10 September 2026 and tracked as CVE-2026-86079.

According to the advisory, the two nodes built REST endpoints by interpolating user-supplied identifiers straight into the request path. A value containing path separators or dot segments could change which endpoint the request actually reached. An operation meant for one document could instead hit another index, or a cluster administration endpoint, using the Elasticsearch credential already stored in n8n.

That last detail is the important one. In agent and workflow platforms, credentials are held by the platform and attached to whatever call a node makes. If an attacker can steer the path, they inherit the permissions of the stored credential without ever seeing it. The advisory describes the affected requests as running "under the stored Elasticsearch credential".

n8n says the issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2. The patch encodes each identifier as a single URL path segment and rejects values that normalise away, meaning inputs that collapse to nothing once dot segments and separators are resolved. Users are advised to upgrade to one of those versions or later.

For administrators who cannot upgrade straight away, the advisory lists three temporary steps. The first is to restrict access to the n8n instance to fully trusted users only. The second is to disable the affected nodes by adding n8n-nodes-base.elasticsearch and n8n-nodes-base.elasticSecurity to the NODES_EXCLUDE environment variable, if those nodes are not needed. The third is to audit existing workflows that use the nodes and check that index and document identifier fields do not accept externally controlled input.

n8n is explicit that these are stopgaps. The advisory states the workarounds "do not fully remediate the risk and should only be used as short-term mitigation measures".

The third workaround points at the underlying design question for anyone running automated workflows. A node is only as safe as the data feeding it. If an identifier field is wired to a webhook, a form submission, an email body or the output of a language model, then whoever controls that upstream data controls part of the request path. The advisory does not describe any real-world exploitation, and no affected users have been named.

The pattern is a familiar one in agentic systems, where components are given credentials and then handed inputs from elsewhere in a pipeline. The root cause here is not a broken credential store or a bypassed permission check. It is a node doing exactly what it was told, with an instruction that had been quietly rewritten by its own input. Encoding the identifier as a single path segment removes that ambiguity: a slash inside a document ID becomes part of the ID rather than part of the route.

The advisory covers the npm package n8n. Operators running self-hosted instances should check their version against the three patched releases and, where the Elasticsearch nodes are not in use, consider excluding them regardless. The issue is now marked as resolved.