CVE-2026-72774: n8n Auth Bypass Vulnerability

CVE-2026-72774 Overview

CVE-2026-72774 is a credential authorization bypass in the n8n workflow automation platform. The flaw affects the HTTP Request node in n8n versions before 1.123.67, 2.31.5, and 2.32.1. An authenticated member with edit access to a shared workflow can reference another user's credential by specifying the credential type through an expression. The pre-execution permission check compares the unresolved expression rather than the resolved credential type, so the ownership check is skipped. At execution time, the credential is loaded and available to the attacker, enabling unauthorized use or exfiltration. Exploitation requires knowing the target credential's identifier. The weakness is classified as [CWE-639] Authorization Bypass Through User-Controlled Key.

Critical Impact
Authenticated workflow collaborators can access credentials they were never granted, enabling exfiltration of API keys, OAuth tokens, and other integration secrets stored in n8n.

Affected Products

n8n versions before 1.123.67
n8n versions before 2.31.5
n8n versions before 2.32.1

Discovery Timeline

2026-08-11 - CVE-2026-72774 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-72774

Vulnerability Analysis

n8n is a workflow automation platform where users build pipelines composed of nodes, including the HTTP Request node used to call external services. Nodes can attach credentials such as API keys or OAuth tokens by referencing a stored credential identifier and a declared credential type. n8n enforces per-user credential ownership: only users granted access to a credential should be able to use it in a workflow.

The authorization check runs before workflow execution. It reads the credential type declared on the node and validates that the invoking user is authorized to use a credential of that type and identifier. The vulnerability arises because the HTTP Request node allows the credential type field to be populated by an n8n expression rather than a literal string.

When the pre-execution check inspects the node, it evaluates the raw expression string rather than the resolved value. The check therefore does not match any real credential type and is effectively skipped. At runtime, n8n resolves the expression and loads the referenced credential without re-validating ownership, handing it to the HTTP Request node for use.

Root Cause

The root cause is inconsistent handling of expressions between the authorization layer and the execution layer. Authorization operates on unresolved input while execution operates on resolved input, creating a time-of-check to time-of-use mismatch in the credential permission model.

Attack Vector

An attacker must be an authenticated n8n member with edit access to a shared workflow and must know the target credential's identifier. The attacker adds an HTTP Request node, references the victim credential's ID, and sets the credential type field to an expression that resolves to the correct type. Executing the workflow triggers the credential load, and the response body or downstream nodes can be used to exfiltrate the secret.

The vulnerability is exploited over the network against the n8n application and does not require user interaction. See the GitHub Security Advisory and the VulnCheck Advisory for further technical detail.

Detection Methods for CVE-2026-72774

Indicators of Compromise

HTTP Request nodes in shared workflows where the credentials.type field contains an n8n expression (={{ ... }}) instead of a literal credential type string.
Workflow execution logs showing a user invoking a credential ID that was not shared with them in the credentials sharing table.
Outbound HTTP requests from the n8n instance to attacker-controlled destinations that echo header values, query parameters, or request bodies containing credential material.

Detection Strategies

Audit the n8n database for workflow node definitions whose credential type parameter is expression-typed rather than a static value.
Correlate credential access events at execution time with the credential sharing ACL, and alert on any user accessing a credential not present in their authorized set.
Review recent shared-workflow edits by non-owner members that added or modified HTTP Request nodes referencing unfamiliar credential IDs.

Monitoring Recommendations

Forward n8n audit and execution logs to a central SIEM and build detections around credential ownership mismatches.
Monitor egress traffic from n8n worker hosts for anomalous destinations, especially requests that carry authorization headers to non-approved domains.
Track credential creation, sharing, and usage as a distinct object type so that unauthorized reuse can be reconstructed after the fact.

How to Mitigate CVE-2026-72774

Immediate Actions Required

Upgrade n8n to 1.123.67, 2.31.5, 2.32.1, or later depending on the release track in use.
Rotate any credentials stored in n8n that could have been referenced by shared-workflow collaborators, prioritizing high-value API keys and OAuth tokens.
Review membership on shared workflows and revoke edit access from users who do not require it.

Patch Information

The n8n maintainers fixed the issue in versions 1.123.67, 2.31.5, and 2.32.1. The patched releases resolve credential type expressions before performing the ownership check so that the authorization decision uses the same value that execution will consume. Refer to the GitHub Security Advisory GHSA-6qc9-mqvw-jg7x for release notes and upgrade guidance.

Workarounds

Restrict workflow sharing so that credential owners do not grant edit access to users who should not use those credentials.
Segment high-value credentials into separate n8n instances or projects with tighter membership.
Audit shared workflows for HTTP Request nodes whose credential type is an expression and remove or replace them until the upgrade is complete.

bash

# Upgrade n8n using npm to a patched release
npm install -g n8n@1.123.67

# Or upgrade a Docker deployment to a patched tag
docker pull n8nio/n8n:1.123.67
docker stop n8n && docker rm n8n
docker run -d --name n8n -p 5678:5678 n8nio/n8n:1.123.67