n8n: Ten Vulnerabilities Fixed on September 10, 2026

Why is n8n such an attractive target?

n8n orchestrates flows between CRM, email, databases, payments and, more and more, AI models. An instance therefore holds high-value credentials for dozens of services and network access into the company. A "medium" flaw in such a tool reads differently from one in an isolated application.

What are the ten advisories published on September 10?

All are rated "medium" in the GitHub advisory database and published the same day:

• CVE-2026-86073 (GHSA-cw9w-vv67-hf73): per-resource OAuth consent bypass through resource substitution with an unbound refresh token; version 2.38.0 only, fixed in 2.38.1.
• CVE-2026-86084 (GHSA-pf83-w3f9-8m37): disabled OIDC SSO endpoints remain active and issue valid sessions; before 1.123.76.
• CVE-2026-86085 (GHSA-cqr2-h44g-v75v): cross-tenant project-member personal data disclosure through a missing per-project scope check on role assignment; 2.38.0 and 2.38.1, fixed in 2.38.2.
• CVE-2026-86994 (GHSA-65xw-2v52-jhxc): disclosure of other users' active workflow IDs and lifecycle events; before 1.123.76.
• CVE-2026-86074 (GHSA-q5wm-mgqx-fv2f): the built-in AI credential setup accepts an unvalidated probe URL from fetched content; 2.38.0 and 2.38.1, fixed in 2.38.2.
• CVE-2026-86993 (GHSA-pq6c-vh67-xpm3): log streaming destinations decrypt credentials without an ownership check; before 1.123.76.
• CVE-2026-86995 (GHSA-qgpw-8g46-w95v): the Git node branch.<name>.remote config key bypasses the sandbox path restriction; before 1.123.76.
• CVE-2026-86080 (GHSA-5m98-cgcr-xx3q): the GitHub trigger skips webhook secret storage in a reuse path, so signature verification fails open; before 1.123.76.
• CVE-2026-86079 (GHSA-f2cp-m7mv-8jpv): path injection in the Elasticsearch and ElasticSecurity nodes through unencoded identifiers; before 1.123.76.
• CVE-2026-86078 (GHSA-679f-58pq-4v2c): prototype pollution leading to denial of service; 2.38.0 and 2.38.1, fixed in 2.38.2.

The exact version ranges are those of the GitHub advisory database; check yours before concluding you are safe.

Who is affected?

Self-hosted instances on the listed versions, first those that share an instance between several users or projects (cross-project leaks, workflow IDs), those that expose webhooks or SSO, and those that run the Git node. A single-user instance behind a VPN has less to fear from isolation flaws, but not from configuration flaws.

How do you detect and test the exposure?

1. Read the version of each instance (interface or n8n --version) and compare it with 1.123.76, 2.38.1 and 2.38.2.
2. Check OIDC: if you disabled it in the interface, test from outside that the sign-in endpoints really respond with an error.
3. Check webhooks: a GitHub webhook must reject a request without a valid signature; send an unsigned request to a test webhook and confirm the refusal.
4. Review log destinations: who can create them, and which credentials are attached?
5. Inventory Git nodes: which repositories, which paths, which rights.

How do you fix it?

Update n8n to 1.123.76 for the 1.x branch, or to 2.38.2 for the 2.x branch. After the update, rotate the credentials stored on any shared or exposed instance, check active SSO sessions and regenerate webhook secrets. Apply least privilege to the service accounts n8n uses.

What changes when an AI agent has access to n8n?

n8n often hosts agents: an "AI Agent" node calls a model, reads emails or tickets, then triggers tools (CRM, email, payment). The credentials for those tools are stored in the instance. A flaw that exposes credentials (log streaming), bypasses SSO (OIDC) or accepts an unsigned webhook (GitHub trigger) gives the attacker the agent's power, not just a user account's.

Advisory CVE-2026-86074 is telling: the built-in AI credential setup accepts a URL taken from fetched content. That is the structure of an indirect prompt injection: read content becomes an instruction steering an outbound request (OWASP LLM01, and LLM06 for excessive rights). A webhook without signature verification plays the same role: anyone can trigger a workflow that contains an agent and its tools. See n8n webhook signature validation and indirect prompt injection.

Controls specific to agents: one credential set per workflow with minimal scope, signed webhooks rejected by default, no URL or path derived from external content without an allowlist, and human approval before write actions. See also AI agent security and, for another recent n8n flaw, CVE-2026-59208 on JWT token exchange.

Why can several medium flaws chain together?

Taken alone, these flaws need conditions: an authenticated account, network access, a specific configuration. Combined, they reinforce each other: a credential read from a log stream opens access to an API, an OIDC session that should have been closed gives a foothold, an unverified webhook triggers the workflow that uses those credentials. This is why an audit looks at the paths between components rather than a single score, and why a rotation of stored secrets after patching is not optional on a shared instance.

What should you check on an agent with the September 2026 n8n flaws?

An agent red team sends booby-trapped content to an n8n workflow (email, ticket, form, webhook call) and watches outbound calls, the credentials used and the actions triggered. The Agent Red Team Express (1,900 euros, 5 days) replays the n8n scenarios on your agent: poisoned webhook, execution node, stored credentials. The method details the approach.

What is the lesson?

Ten medium advisories in one day describe a project that fixes quickly. For a tool that holds the keys to the whole company, "medium" mostly means update without delay and check what the agent can reach.

Further reading

• agent supply chain
• unauthenticated Langflow RCE
• Langflow auth bypass