EUVD-2026-38624
GHSA-jr54-jwhj-55gp
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/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:N/PR:N/UI:N/VC:L/VI:N/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
Sign-in response timing differed between known and unknown email addresses because the unknown-user branch returned without performing a password hash comparison.
Details
The unknown-user branch in auth.service.ts now performs a bcrypt.compare against a fixed dummy hash so the response time of failed sign-ins is approximately independent of whether the address exists. Rate limiting on the sign-in endpoint is implemented in the Enterprise build only and is not affected by this advisory.
Impact
A network-positioned attacker could enumerate registered email addresses by timing sign-in responses. Exploitation requires only the ability to send unauthenticated sign-in requests.
Credit
This issue was reported by @AndyAnh174.
AnalysisAI
User enumeration via observable timing discrepancy in NocoDB's sign-in endpoint allows network-positioned attackers to determine whether an email address is registered. The authentication service (auth.service.ts) returned immediately for unknown users without executing a bcrypt password hash comparison, producing measurably shorter response times than for known users - a classic timing side-channel. No public exploit has been identified at time of analysis, but the technique requires no privileges and is straightforward to execute against any network-accessible NocoDB instance running versions prior to 2026.04.1.
Technical ContextAI
The root cause is CWE-208 (Observable Timing Discrepancy): the authentication flow in auth.service.ts short-circuited on the unknown-user branch by returning a failure response without invoking bcrypt.compare, which is an intentionally slow cryptographic operation. For known users, the code path always runs bcrypt.compare against the stored hash, introducing a consistent computational delay (~100-300ms depending on bcrypt cost factor). This asymmetry lets an attacker distinguish the two code paths by measuring HTTP response latency. The affected package is pkg:npm/nocodb, distributed via npm. The fix applies a constant-time mitigation by performing bcrypt.compare against a fixed dummy hash even when no user record is found, equalizing response time between the two branches.
RemediationAI
Upgrade NocoDB to version 2026.04.1 or later, which resolves the timing discrepancy by performing bcrypt.compare against a fixed dummy hash for unknown users. Release notes and package are available at https://github.com/nocodb/nocodb/releases/tag/2026.04.1. If immediate patching is not feasible, deployments should place a reverse proxy or WAF in front of NocoDB's sign-in endpoint and enforce per-IP rate limiting externally - note this replicates the Enterprise-only control and requires operational overhead to maintain. Adding artificial response delay at the application layer (e.g., via middleware) is a weaker workaround because jitter in network latency can be averaged out with enough requests. Restricting sign-in endpoint access to known IP ranges is the strongest compensating control but may not be viable for internet-facing deployments. Enterprise customers should verify that built-in rate limiting on the sign-in endpoint is active.
Same weakness CWE-208 – Observable Timing Discrepancy
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today