CVE-2026-54305High (CVSS 8.9)Fixed3 min read
Cross-tenant credential takeover in n8n's Dynamic Credentials endpoints
Three Enterprise Dynamic Credentials endpoints in n8n authenticated the session but never checked that the caller owned the target workflow or credential. Any authenticated user could enumerate, overwrite via OAuth, or revoke another tenant's stored credentials, and run workflows under a hijacked OAuth identity. Fixed in 1.123.55, 2.25.7, and 2.26.2.
- Vendor
- n8n
- Product
- n8n (Enterprise Edition)
- Weakness
- CWE-639 / CWE-863
- Affected
- < 1.123.55, < 2.25.7, < 2.26.2
- Fixed in
- 1.123.55, 2.25.7, 2.26.2
- Advisory
- GHSA-2j5h-858j-5mpf
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L
Disclosure timeline
Jun 10, 2026
Advisory GHSA-2j5h-858j-5mpf published and CVE-2026-54305 assigned (High, CVSS 8.9). Fixed in 1.123.55, 2.25.7, and 2.26.2.
n8n is a workflow automation platform. In a shared or Enterprise deployment it is multi-tenant: different users own their own workflows and their own credentials, and a credential often holds a live OAuth token for a third-party service. The whole point of that boundary is that your credentials are yours. This bug crossed it.
Reported and credited alongside @Solidscripting.
The bug
The Enterprise Dynamic Credentials feature exposes three endpoints. All three authenticated the caller's n8n session, and then stopped there. They never checked that the session actually owned the workflow or credential it was acting on. Authorization answered "are you logged in" when it needed to answer "do you own this resource."
Because the target credential and workflow are addressed by identifier, an authenticated user in one tenant could point these endpoints at resources belonging to another tenant and the server would carry out the request.
What that allowed
Three distinct actions, escalating in severity:
- Enumerate. Read the identifiers, names, and types of credentials that belong to other users. On its own that is an information leak, and it also hands an attacker the exact IDs needed for the next two steps.
- Overwrite. Initiate an OAuth authorization flow that rewrites another user's stored credential token. After this, the victim's credential holds a token tied to the attacker's OAuth identity.
- Revoke. Delete another user's stored tokens outright, breaking their workflows.
The overwrite is the sharp end. Once a victim's credential points at the attacker's OAuth identity, any workflow that uses that credential runs against the attacker's account. Data the workflow was meant to send to the victim's service can flow to the attacker instead, and actions the workflow takes execute under the attacker's identity. That is why this rates High rather than a simple info leak: it is a full cross-tenant credential takeover, not just disclosure.
The fix
n8n added the missing per-resource ownership and scope checks to the three Dynamic Credentials endpoints, so each request is now validated against the caller's ownership of the specific workflow or credential it names. The fix shipped across all three supported release lines: 1.123.55, 2.25.7, and 2.26.2.
If you run n8n
Upgrade to 1.123.55, 2.25.7, or 2.26.2 or later, whichever matches your release line. Because a credential's OAuth token could have been overwritten or revoked while you were exposed, treat the upgrade as a prompt to review and re-authorize Dynamic Credentials connections rather than a fix that silently restores them.