An Enterprise dynamic-credential authorization callback could associate an OAuth provider token with the n8n member who initiated the flow instead of the person who consented. The attacker needed to send the authorization link to another person who then completed a valid provider consent outside a matching n8n browser session. The initiating account could…
Inspect the ClaimsCase · DiggingBeagle record
n8n Enterprise OAuth callback attached consent to the wrong workflow user
An Enterprise dynamic-credential authorization callback could associate an OAuth provider token with the n8n member who initiated the flow instead of the person who consented. The initiating account could receive a provider token belonging to the consenting user under its own dynamic credential record.
Scope
The attacker needed to send the authorization link to another person who then completed a valid provider consent outside a matching n8n browser session. The weakness required user interaction and a particular Enterprise credential flow; it does not establish broad OAuth compromise.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
The cited primary technical report or advisory supports the stated mechanism within its reported scope. The assessment does not infer a production breach, a victim count or a comparable impact score from a laboratory result. A maintainer or advisory names a patched release; that does not prove every deployed instance has updated. Boundary: An OAuth consent event is not proof that the original workflow owner is the person who just authenticated to the third-party provider.
Assessed Oct 29, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-CP23-N8N-OAUTH-WRONG-PRINCIPAL-1 · CLM-ENRICH-20261029-22 · n8n Enterprise dynamic OAuth callback identity binding advisory
At a glance
The initiating account could receive a provider token belonging to the consenting user under its own dynamic credential record.
Read the implicationsThe weakness required user interaction and a particular Enterprise credential flow; it does not establish broad OAuth compromise.
Limits and uncertaintyFull account
An Enterprise dynamic-credential authorization callback could associate an OAuth provider token with the n8n member who initiated the flow instead of the person who consented.
The attacker needed to send the authorization link to another person who then completed a valid provider consent outside a matching n8n browser session. The initiating account could receive a provider token belonging to the consenting user under its own dynamic credential record.
The weakness required user interaction and a particular Enterprise credential flow; it does not establish broad OAuth compromise. Use the patched n8n release and bind OAuth state, current signed-in user, provider consent and target credential to the same principal.
Evidence interpretation and control boundary. An OAuth consent event is not proof that the original workflow owner is the person who just authenticated to the third-party provider. The missing binding between the callback and an active n8n principal allowed a token issued after a victim’s consent to be attached to a different member’s credential record. The attack requires the victim to follow a link and grant consent; it does not silently steal tokens from an uninvolved user.
Mechanism and trust boundary
- 01
Step
- 02
Step
- 03
Step
Claims & evidence
CLM-ENRICH-20261029-22The n8n Enterprise OAuth advisory describes an end-user credential-connect callback that could associate a consenting person’s provider token with the wrong n8n member when the necessary session check was absent.supported
Basis: reported finding
- supportsn8n Enterprise dynamic OAuth callback identity binding advisoryprimary disclosure
GHSA-426f-xmcv-g8pg: attack steps, identity confusion and patched versions
CLM-CP23-N8N-OAUTH-WRONG-PRINCIPAL-1An Enterprise dynamic-credential authorization callback could associate an OAuth provider token with the n8n member who initiated the flow instead of the person who consented. The attacker needed to send the authorization link to another person who then completed a valid provider consent outside a matching n8n browser session. The initiating account could receive a provider token belonging to the consenting user under its own dynamic credential record.supported
Basis: reported finding
- supportsn8n Enterprise dynamic OAuth callback identity binding advisoryprimary disclosure
GHSA-426f-xmcv-g8pg: attack steps, identity confusion and patched versions
Implications
The initiating account could receive a provider token belonging to the consenting user under its own dynamic credential record.
Controls and mitigations
- Use the patched n8n release and bind OAuth state, current signed-in user, provider consent and target credential to the same principal.
Unknowns and contradictions
- The weakness required user interaction and a particular Enterprise credential flow; it does not establish broad OAuth compromise.
Sources and citation
Material revision history
- Oct 29, 2026 · Canonical change recorded · new in release · revision 202