CVE-2026-29792 is a critical flaw (CVSS 9.8) in Feathers, the TypeScript and JavaScript API framework. In versions 5.0.0 through 5.0.41 of @feathersjs/authentication-oauth, an unauthenticated request to the OAuth callback can return a valid access token for an existing user. The fix is version 5.0.42.
What's affected
Per the GitHub advisory, @feathersjs/authentication-oauth versions 5.0.0 up to and including 5.0.41 are affected, and 5.0.42 or later is patched. The NVD record words it as 5.0.0 to before 5.0.42.
The issue applies to apps that enable OAuth login in Feathers 5. If you only use local username and password authentication, the OAuth callback route is not part of your setup, but check your configuration to be sure.
How to check if you're exposed
List the installed version in each Feathers service:
npm ls @feathersjs/authentication-oauth
npm ls @feathersjs/feathers
Then look at your config/default.json or equivalent for an authentication.oauth block. If providers are configured there, the callback route at /oauth/:provider/callback is live in your app. Check lockfiles in every service and monorepo package, since the dependency can be pulled in indirectly.
What to do now
- Upgrade
@feathersjs/authentication-oauthto 5.0.42 or later, and keep the other@feathersjspackages on matching versions. - Redeploy every service that uses OAuth login, then confirm the installed version in the running build, not only in source control.
- Review authentication logs from the exposure period for tokens issued without a matching provider login.
- Consider rotating the JWT secret if you suspect misuse. This signs out every user, so plan for it.
- Add the package to your dependency inventory and alerts so framework advisories reach you quickly. Run the free in-browser dependency scan at https://gold.safeguard.sh/scan to see whether the affected package is in your lockfile or SBOM.
Why it matters
The advisory explains the cause in plain terms. The OAuth service builds its authentication payload with a fallback chain. When the Grant library has no session or state to work with, the code falls back to the raw request query string. An attacker who never started an authorize flow can therefore supply a forged profile in the query, and that profile drives the user lookup and token creation. The server never talks to the real OAuth provider.
The record lists the weakness as CWE-287, improper authentication, and the NVD entry rates it 9.8 with no privileges or user interaction needed. The lesson for framework authors and users alike is that data from the request should never stand in for a result that only the identity provider can produce. The record does not mark this as exploited in the wild, and it is not in the CISA KEV catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to patch if I never enabled OAuth?
The advisory describes the OAuth callback. Apps without OAuth providers configured are unlikely to be exposed, but upgrade anyway when you next update dependencies.
Which package holds the fix?
@feathersjs/authentication-oauth, version 5.0.42. The related CVE-2026-29793 is fixed in @feathersjs/mongodb at the same version number.
Sources
Last reviewed: 19 October 2026.
