Am I affected by n8n: Per-Resource OAuth Consent Bypass via Unbound Refresh Token Resource Substitution? What should I do?
In n8n, the OAuth token endpoint tied an authorization code's first access token to the resource the user approved, but not its refresh token.
Affected: n8n < 2.37.7 and n8n 2.38.0. Fixed in: 2.37.7. What should you check, and what should you do about it?
Full incident page with sources: https://agentarmorhq.com/incidents/2026/09/cve-2026-86073-n8n (opens external site)
1 answer
Am I affected? Affected: n8n < 2.37.7 and n8n 2.38.0. Fixed in: 2.37.7.
- Check your version: run
npm ls n8n. Versions >= 2.38.0, < 2.38.1 of n8n are affected.
What to do now
- Upgrade to the fixed version: run
npm install n8n@2.38.1(first patched version 2.38.1). - Upgrade to n8n 2.37.7 or 2.38.1, or a later version.
- If upgrading is not possible right away, restrict access to the n8n instance to fully trusted users only.
- Audit connected OAuth clients and revoke any that are not recognized or no longer needed.
- After upgrading, require re-authorization for all existing OAuth clients, because previously issued refresh tokens did not store the original resource binding.
General practice, not from the source: if the affected software could read tokens or credentials, rotate them after upgrading; pin versions and review changes before updating tools your agents run.
Sources
- GitHub Advisory Database: https://github.com/advisories/GHSA-cw9w-vv67-hf73 (opens external site)
Full incident page: https://agentarmorhq.com/incidents/2026/09/cve-2026-86073-n8n (opens external site)
Did this work for you?- Check your version: run