CVE-2026-86073 in n8n
Summary
by MITRE • 09/08/2026
n8n is an open source workflow automation platform. Prior to 2.37.7 and 2.38.1, the OAuth token endpoint bound an authorization code's first access token to the consented resource but did not bind its refresh token. Refreshing checked only that the requested resource was registered, not that it matched the original grant. An OAuth client approved for one workflow could substitute a different workflow URL in the resource parameter and obtain a valid token for an unapproved workflow accessible to the consenting user. This issue is fixed in versions 2.37.7 and 2.38.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in n8n, specifically affecting versions prior to 2.37.7 and 2.38.1, represents a critical flaw in the implementation of OAuth token binding mechanisms within its workflow automation framework. This issue stems from an inconsistency in how authorization grants are validated during different stages of the authentication flow. When a user initiates an OAuth connection for a specific workflow or resource, the platform correctly binds the initial access token to that authorized consented resource. However, the logic governing refresh tokens fails to enforce this same binding constraint. The system only verifies that the requested resource exists and is registered within the application but neglects to confirm that it matches the original resource specified in the authorization grant. This architectural oversight creates a significant security gap where the scope of access granted by the user can be expanded beyond what was explicitly consented to during the initial authentication handshake.
From an operational perspective, this flaw allows for unauthorized privilege escalation and lateral movement within the n8n environment. An attacker who has obtained valid credentials or manipulated the OAuth flow could exploit this discrepancy by substituting a different workflow URL in the resource parameter when requesting a refresh token. Because the server does not validate that the new resource aligns with the original grant, it issues a valid access token for an unapproved workflow. This effectively bypasses the intended isolation between workflows and resources, allowing clients approved for one specific task to gain access to other sensitive operations accessible by the consenting user. The impact is particularly severe in multi-tenant or shared environments where distinct workflows handle different data sets or critical business logic, as it undermines the principle of least privilege and allows unauthorized actors to execute actions they were not originally permitted to perform.
This vulnerability aligns with CWE-284 Improper Access Control, specifically relating to insufficient validation of access control parameters during token refresh operations. It also maps directly to MITRE ATT&CK technique T1528 Steal Application Access Token, as the attacker leverages valid credentials and manipulates the OAuth flow to acquire tokens for unauthorized resources. The failure to bind refresh tokens to their original authorization context is a common pitfall in OAuth implementations that can lead to session hijacking or privilege escalation if not properly mitigated through strict resource validation at every token issuance point.
To mitigate this risk, organizations running n8n must immediately upgrade to version 2.37.7 or later, where the binding logic has been corrected to ensure refresh tokens are strictly tied to their original consented resources. For environments that cannot update immediately due to compatibility constraints, administrators should enforce strict validation of resource parameters in custom OAuth integrations and monitor for unusual patterns of token requests involving different workflow URLs than those originally authorized. Additionally, implementing short-lived access tokens with robust rotation policies can reduce the window of opportunity for exploitation if a refresh token is compromised. Regular audits of OAuth client configurations and consent scopes are recommended to ensure that no unintended resources remain accessible through manipulated grant parameters.