CVE-2026-86073 is a high severity OAuth flaw in n8n. The first access token was tied to the approved workflow, but the refresh token was not, so a client approved for one workflow could ask for a token for another one the same user can reach. Upgrade to 2.37.7 or 2.38.1.
What's affected
- Product: n8n, the OAuth token endpoint.
- Affected: versions before 2.37.7 and before 2.38.1.
- Fixed: 2.37.7 (released 2 September 2026) and 2.38.1 (released 1 September 2026), or later.
- Effect: a client approved for one workflow could obtain a valid token for an unapproved workflow accessible to the consenting user.
Severity in the record: High, CVSS 7.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L).
Weakness class: CWE-863 (Incorrect Authorization).
How to check if you're exposed
- Find your version. For a global npm install,
n8n --versionprints it. For Docker, rundocker exec my-n8n n8n --version, or read the image tag. - Compare it with the fixed releases for your line, listed above.
- Check whether you use n8n's OAuth server features to let outside clients or agents call workflows. If not, this flaw has little to act on.
- List the OAuth clients registered on the instance and the workflows they were approved for.
What to do now
- Upgrade to 2.37.7, 2.38.1 or a later release.
- Expect clients to re-authorize. The fix pull request says existing refresh tokens are cleared by migration, and clients run the authorization flow again on their next refresh. Access tokens stay valid for up to an hour.
- Review registered OAuth clients and remove any you do not recognize.
- Review which workflows each client can reach, and narrow the list.
- Tell integrators in advance about the one time re-authorization.
Why it matters
OAuth lets a user approve a client for one resource. The server must keep that binding for every token it issues from the approval, including later refreshes. Here the first access token carried the resource but the refresh token did not, and the refresh only checked that the requested resource existed. A client could then name a different workflow. The weakness is incorrect authorization, CWE-863.
The fix stores the resource with the refresh token, reuses it when a request names none, and rejects any other with an invalid target error before the token is consumed. The user had to consent in the first place and could already reach the workflow, so the harm is a client exceeding its approval. The record does not claim exploitation in the wild.
Quick check
Will the fix log my users out?
Not live sessions, per the fix notes: access tokens stay valid for up to an hour. Clients must re-run the authorization flow when they next refresh.
Sources
Last reviewed: 18 October 2026.
