EUVD-2026-38614
GHSA-8m7c-hf24-5g47
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (https://github.com/nocodb/nocodb) · only source for this CVE.
CVSS VectorVendor: https://github.com/nocodb/nocodb
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionCVE.org
Summary
Two concurrent token-exchange requests using the same OAuth authorization code could each mint a distinct valid (access_token, refresh_token) pair, breaking the single-use guarantee that PKCE relies on.
Details
The token-exchange flow read is_used and called markAsUsed as an unconditional update at the end of the path. A new OAuthAuthorizationCode.claimByCode method now performs an atomic compare-and-swap (WHERE code = ? AND is_used = false) and is called immediately before OAuthToken.insert, after redirect-URI, PKCE, and client authentication have all succeeded. Only the first concurrent caller's UPDATE wins; the rest see invalid_grant: Authorization code has already been used.
Impact
An attacker who has observed an authorization code and the corresponding PKCE verifier (for example through a malicious OAuth-aware client or by racing a real exchange) could obtain a long-lived refresh token in addition to the legitimate one.
Credit
This issue was reported by @eddieran.
AnalysisAI
OAuth authorization code exchange in NocoDB versions up to 2026.05.0 is vulnerable to a race condition that breaks the single-use guarantee enforced by PKCE. By submitting two or more concurrent token-exchange requests before the server atomically marks the authorization code as consumed, an attacker who controls a malicious OAuth client can obtain multiple valid (access_token, refresh_token) pairs from a single authorization code, resulting in unauthorized long-lived session access alongside the legitimate token. Fixed in 2026.05.1 via an atomic compare-and-swap database operation; no public exploit has been identified at time of analysis and this vulnerability is not listed in the CISA KEV catalog.
Technical ContextAI
This is a CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization) race condition in NocoDB's OAuth 2.0 token exchange endpoint. OAuth 2.0 with PKCE requires authorization codes to be strictly single-use - once redeemed, they must be atomically invalidated. The original implementation read the is_used flag and then called markAsUsed as a separate, non-atomic write at the end of the exchange path, creating a classic time-of-check/time-of-use (TOCTOU) window. Two concurrent requests could both read is_used = false, pass all validation (redirect-URI, PKCE verifier, client authentication), and each independently proceed to insert a token pair. The fix introduces a new OAuthAuthorizationCode.claimByCode method that performs an atomic SQL compare-and-swap (UPDATE ... WHERE code = ? AND is_used = false), called immediately before OAuthToken.insert - only the first transaction's UPDATE matches a row, causing all subsequent concurrent attempts to receive invalid_grant: Authorization code has already been used. The affected package is pkg:npm/nocodb as documented in GitHub Advisory GHSA-8m7c-hf24-5g47.
RemediationAI
Upgrade NocoDB to version 2026.05.1 or later; this is the vendor-released patch that replaces the non-atomic markAsUsed pattern with the atomic OAuthAuthorizationCode.claimByCode compare-and-swap fix. The release is available at https://github.com/nocodb/nocodb/releases/tag/2026.05.1 and the advisory at https://github.com/nocodb/nocodb/security/advisories/GHSA-8m7c-hf24-5g47. If an immediate upgrade is not feasible, consider temporarily disabling third-party OAuth client integrations if the NocoDB deployment supports alternative authentication methods (e.g., email/password login), accepting that OAuth-dependent workflows will be unavailable during the interim. Restricting network-level access to the token exchange endpoint to a trusted allowlist of client IP addresses can reduce the attack surface by limiting who can attempt the concurrent-request race, but this does not eliminate the underlying race condition and may be impractical if OAuth clients are distributed or external. There is no evidence that compensating database-level locking can be applied externally without code changes.
Same weakness CWE-362 – Race Condition
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today