NocoDB CVE-2026-121736 lets an unauthenticated request mint OAuth codes
NocoDB 0.300.0 before 2026.08.0 contains an unauthenticated OAuth authorization-code creation flaw tracked as CVE-2026-121736. The vulnerable path is POST /api/v2/oauth/authorize. The public description says an unauthenticated attacker can create OAuth authorization codes.
An authorization code is not the same as an access token, but it is a credential-bearing step in an OAuth flow. The impact depends on the registered client, redirect handling, code lifetime, token-exchange checks, and what the resulting token can access. Those conditions should be verified rather than assumed. The endpoint still deserves urgent attention because the normal trust assumption is that an authorization code appears only after a user has authenticated and consented.
What went wrong at the boundary
The OAuth authorization endpoint is where a resource owner approves a client's request. In a conventional flow, the server authenticates the user, checks that the client is registered, verifies the redirect URI, and records the scope. Only then does it issue a code that the client can exchange.
The public advisory describes the failure as missing authentication in the authorize handler. That does not prove every NocoDB deployment is exploitable in the same way. An installation may have disabled OAuth, restricted network access, or configured clients in a way that limits the result. The defensible conclusion is that the endpoint must not create a code for an unauthenticated requester, and that this behavior needs to be tested after the upgrade.
Treat OAuth objects as credentials
Security teams often focus on access tokens because they are presented directly to APIs. Authorization codes are temporary, but they are still part of a chain that produces a token. A code should be bound to a client, redirect URI, scope, and user or resource owner. It should expire quickly and be single use.
If an attacker can create a code, the next questions are: Which client can exchange it? Which redirect URI is accepted? What scope is attached? Does the token inherit a useful identity? Can the attacker force a victim to complete a flow? The code itself is only one part of the exploit path.
Review the application's registered OAuth clients and redirect URI rules. Look for wildcard redirects, client secrets stored in public clients, and test clients left in production. Check whether the token endpoint validates the client identity and whether a code can be exchanged more than once.
Investigate exposed instances
Upgrade to NocoDB 2026.08.0 or later, then verify the running version on every node. Self-hosted deployments often run behind a reverse proxy, so the version visible in a container image and the version serving the public hostname may diverge. Check the actual process and the database migration state.
Search logs for requests to POST /api/v2/oauth/authorize that were not associated with an authenticated session or an expected client flow. Record source address, user agent, redirect URI, and client identifier. Do not retain authorization codes, client secrets, or full tokens in incident notes.
If a suspicious code might have been exchanged, review token issuance and API access during the code lifetime and afterward. Rotate any client secret that could have been exposed. Revoke sessions or tokens created through an unexpected flow. The fix does not automatically invalidate credentials created before it.
Reduce the exposed interface
NocoDB should not expose its API to the public internet unless the deployment requires it. Put the service behind an authenticated gateway, restrict management endpoints to a trusted network, and use a reverse proxy that preserves client identity without trusting arbitrary forwarding headers.
Review OAuth configuration separately from general user authentication. A working login page does not prove that the authorize endpoint is protected. Use an unauthenticated test client and confirm that the endpoint rejects the request before any code is created.
Monitor for unexpected client registrations and redirect URI changes. Alert when an authorization code is issued for a client that has not been used recently or when the request originates outside the expected network. These controls make the next OAuth configuration mistake easier to detect.
Top comments (0)