The n8n OAuth Authorize Endpoint Vulnerability, Explained
What the n8n OAuth authorize endpoint vulnerability (GHSA-3qcw-p65v-c7vq) is, which n8n versions it affects, and what to do now, per GitHub's September 30, 2026 advisory.
Checked against the cited sources on .
What Changed: The n8n Security Advisory, September 2026
On September 30, 2026, GitHub published a security advisory for the n8n npm package describing what it calls "Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint," tracked as GHSA-3qcw-p65v-c7vq. If your team is trying to understand the n8n OAuth authorize endpoint vulnerability, the advisory itself is the place to start, and this article follows what it states point by point. GitHub's own security overview page for the n8n-io/n8n repository lists this advisory as published Sep 30, 2026 by Matsuuu, and rated High severity, which corroborates the date and rating given in the advisory.
The advisory's core finding is about an OAuth client persistence vulnerability: OAuth client records created through the authorize endpoint without any authentication get no size limit, no expiry and no deletion path applied, in the advisory's own wording. In practice that means an unauthenticated caller can keep adding client records indefinitely, since nothing in the flow the advisory describes clears them out. We think the fact that this was reported and disclosed through GitHub's standard advisory process is a good sign for n8n's security posture, even though the underlying bug is a real one to fix.
Sources: Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
Who Is Affected: n8n Versions and the n8n Unauthenticated OAuth Client Issue
The advisory is specific about the n8n OAuth authorize endpoint vulnerability's version scope, also described as the n8n unauthenticated OAuth client issue: it lists affected n8n npm package versions as those before 2.42.1 and before 2.41.4, with the fix shipped in 2.42.1 and 2.41.4.
| Branch | Affected versions | Patched version |
|---|---|---|
| 2.42.x line | Before 2.42.1 | 2.42.1 or later |
| 2.41.x line | Before 2.41.4 | 2.41.4 or later |
What the advisory does not say matters just as much here. It does not state whether n8n Cloud or other hosted plans are affected or already patched on n8n's side, and it does not distinguish between the Community (self-hosted) and Enterprise editions of n8n. We'd caution against reading that silence as reassurance: an advisory that is quiet about hosted plans or editions has simply not addressed them, not ruled out a problem, so teams should still check their own deployment rather than assume they are covered.
How the Vulnerability Works, and Why OAuth Client Records Matter
n8n's authorize endpoint is part of the OAuth flow a workflow uses when it needs to hand off to an external service for authorization. This is the mechanism at the center of the n8n OAuth authorize endpoint vulnerability. The advisory describes the problem as records created at that endpoint persisting with no size limit, no expiry and no deletion path, even though the endpoint itself requires no authentication to call. Each call appears to leave behind a client record that nothing in the system later removes.
GitHub's advisory rates the issue High severity, which the advisory itself states rather than something this article infers. That rating is part of why reading the advisory directly, rather than secondhand summaries, matters for teams verifying their own exposure.
Sources: Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
What to Do Now
The advisory's own stated fix is to run a patched version: 2.42.1 or later on the 2.42.x line, or 2.41.4 or later on the 2.41.x line. Upgrading promptly is our own editorial suggestion here, not a recommendation the advisory itself spells out beyond naming the patched versions, and we think it is the right call precisely because the advisory frames its workarounds as incomplete.
If an immediate upgrade is not possible, the advisory lists several workarounds, including monitoring database size for unexpected growth alongside restricting network access and reviewing Form or Chat Trigger nodes that use n8nUserAuth. The advisory is explicit that these do not fully remediate the risk and are meant only as short-term mitigation, a limitation worth repeating because it is easy to treat a workaround list as a fix. Our practical take: apply all of the listed workarounds together rather than picking one, and keep the upgrade on the schedule regardless.
What the Advisory Leaves Unstated
Beyond editions and hosted plans, the advisory lists no known CVE and no CWEs for this issue, so there is no independent identifier to cross-reference against other trackers. It also does not quantify how large a client table could grow, how much disk space typical records consume, or how quickly growth could become a practical problem for a given deployment. Those are gaps the advisory itself leaves open rather than omissions in this summary.
GitHub's security page for the n8n-io/n8n repository shows this advisory alongside several other advisories published the same day, September 30, 2026. That is an editorial suggestion in this article rather than something the advisory itself recommends: reviewing the fuller list may help teams confirm this is not the only relevant fix in the batch.
Sources: Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
