CVE-2026-45732: n8n OAuth Credential Hijacking via Privilege Escalation

Technical summary

The vulnerability stems from improper authorization checks in the OAuth1 and OAuth2 credential reconnect endpoints. These endpoints check for credential:read permission instead of the more restrictive credential:update permission required to modify stored tokens. An authenticated attacker with read-only access to a shared credential can exploit this by calling the reconnect endpoint and supplying OAuth tokens obtained from an external service under their control. The endpoint then overwrites the legitimate credential's token material with the attacker's tokens. Subsequent workflow executions that authenticate via this credential will use the attacker's OAuth identity, creating a persistent backdoor for data exfiltration or service hijacking. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key), where the permission model fails to enforce the principle of least privilege for state-modifying operations.

Business impact

This vulnerability enables persistent compromise of shared integrations and workflows. An attacker with minimal access (read-only) can silently redirect any workflow using a shared credential to operate under their identity without triggering alerts. This poses severe risks: sensitive data processed by workflows may be exfiltrated to attacker-controlled endpoints; shared integrations (e.g., CRM, marketing automation, data warehouse connectors) can be hijacked to perform unauthorized actions on downstream systems; and the attack is difficult to detect because the credential appears to be functioning normally. Organizations relying on n8n for multi-tenant or shared workflow scenarios face data breach, compliance violations, and loss of trust in their automation layer.

Affected systems

The vulnerability affects n8n versions prior to 1.123.43 (likely 1.x branch), 2.20.7 (2.20.x branch), and 2.22.1 (2.22.x branch). Any deployment of these versions with OAuth-based credentials and multi-user or shared credential access is at risk. Self-hosted and cloud-hosted instances are both vulnerable. The attack requires network access to the n8n instance and valid authentication, so it is not exploitable by unauthenticated users, but internal threats and compromised low-privilege accounts represent realistic attack vectors.

Exploitability

The attack is moderately exploitable in typical n8n deployments. It requires an authenticated user account (lowering the barrier compared to unauthenticated exploits) but does not require elevated privileges—any read-only user can trigger the vulnerability. The attack is deterministic and does not depend on user interaction; the attacker can initiate the reconnect flow and supply their own tokens with certainty of success. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects that once exploited, confidentiality and integrity are severely compromised. The fact that it is not currently tracked in the Known Exploited Vulnerabilities (KEV) catalog does not diminish its risk, particularly in organizations where low-privileged users have access to shared credentials.

Remediation

Organizations should immediately upgrade to the patched versions: 1.123.43 or later (for 1.x), 2.20.7 or later (for 2.20.x), or 2.22.1 or later (for 2.22.x). The fix corrects the authorization logic to require credential:update instead of credential:read, ensuring only users with explicit update permissions can trigger token reconnection. Pending patching, organizations should restrict read-only access to sensitive OAuth credentials, audit which users have read access to shared credentials, and monitor credential reconnect operations for suspicious patterns. In high-security environments, consider segregating credential access by workflow and disabling OAuth reconnect features if not actively used.

Patch guidance

Apply updates according to your n8n deployment model: for self-hosted instances, upgrade the n8n application to version 1.123.43, 2.20.7, or 2.22.1 (or later) depending on your current branch. For cloud-hosted (n8n Cloud) deployments, verify that your instance has been automatically updated by n8n; if manual action is required, follow n8n's documentation. Test patched instances in a staging environment first to ensure backward compatibility with existing workflows and credentials. After patching, review credential permissions to enforce least-privilege access and ensure that users have only the minimum necessary access level to credentials they need.

Detection guidance

Monitor n8n audit logs for calls to credential reconnect endpoints (typically in the OAuth1 or OAuth2 provider routes) initiated by users with only read-level permissions to those credentials. Alerting on reconnect operations followed by changes to stored token metadata is a strong signal. Additionally, inspect workflow execution logs for unexpected changes in the OAuth identity under which workflows are running; if a workflow previously authenticated as 'user-owned-credential' and suddenly begins executing under a different identity, investigate immediately. Network-level detection is challenging unless you can inspect API payloads, but monitoring for repeated failed reconnect attempts followed by success may indicate probing. Ensure your n8n instance logging includes full authentication context and credential access events.

Why prioritize this

This vulnerability should be prioritized for immediate patching due to the combination of high exploitability (any authenticated user, no special conditions), high impact (persistent workflow hijacking, data exfiltration), and ease of attack (simple API call with attacker-supplied tokens). The CVSS 8.1 HIGH score reflects these factors. Unlike more niche vulnerabilities, this affects the core trust model of shared credential management in n8n, a widely-used automation platform. Organizations with shared workflows or multi-user credential access face compounded risk. The absence of KEV status should not delay remediation; internal threats and low-privileged account compromises can exploit this readily.

Risk score, explained

The CVSS 3.1 score of 8.1 (HIGH) is appropriate: Network-accessible endpoints (AV:N), low attack complexity (AC:L), and low privilege requirement (PR:L) ensure broad exploitability. The lack of user interaction (UI:N) and unchanged scope (S:U) confirm that the attacker alone drives the attack. High impact to both confidentiality and integrity (C:H/I:H) reflects that the attacker can exfiltrate data and persistently redirect workflows. No availability impact (A:N) is correct since the credential itself continues to function. The score underscores that this is a serious privilege-escalation and data-protection risk requiring urgent action.

Frequently asked questions