EUVD-2026-52976
GHSA-qq7f-jmv3-wgr8
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/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
Network-reachable endpoint (AV:N) requiring an existing low-privilege auth token (PR:L), high complexity per description (AC:H), limited impact across all pillars, no scope change.
Primary rating from Vendor (vuldb).
CVSS VectorVendor: vuldb
Lifecycle Timeline
2DescriptionCVE.org
A vulnerability was identified in Baserow up to 2.3.2. Affected by this vulnerability is the function verify of the file backend/src/baserow/api/two_factor_auth/views.py of the component 2FA Verify Endpoint. Such manipulation leads to improper authentication. The attack may be launched remotely. This attack is characterized by high complexity. The exploitation appears to be difficult. Upgrading to version 2.3.3 addresses this issue. You should upgrade the affected component. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.
AnalysisAI
Improper authentication in Baserow's 2FA verify endpoint (versions 2.3.0-2.3.2) allows a low-privileged remote attacker to manipulate which user identity the 2FA verification applies to, by supplying a different user identifier in the HTTP request body rather than relying on the authenticated session token. The affected component is the verify function in backend/src/baserow/api/two_factor_auth/views.py, confirmed by the 2.3.3 release refactor note referencing GitHub issue #5743. Exploitation is characterized as high complexity (CVSS 4.0 AV:N/AC:H/PR:L), and no public exploit or CISA KEV listing has been identified at time of analysis.
Technical ContextAI
Baserow is an open-source no-code database platform (an Airtable alternative) with a REST API backend written in Python/Django. The vulnerability resides in the 2FA authentication layer, specifically the verify function in backend/src/baserow/api/two_factor_auth/views.py. The root cause is CWE-287 (Improper Authentication): the endpoint resolved the user's identity from the HTTP request body rather than from the authentication token already established by the session. A correctly implemented 2FA verify flow must bind the one-time code check to the identity proven by the auth token - accepting a caller-supplied user identifier instead breaks the authentication chain and allows the request body to silently override the effective principal. The 2.3.3 release notes confirm the fix: 'Simplify 2FA verify endpoint to resolve user identity from the authentication token instead of the request body (issue #5743).' The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N) indicates this is a network-reachable, single-system-scope flaw with limited but real impact.
RemediationAI
Upgrade to Baserow 2.3.3 immediately, which resolves the vulnerability by refactoring the 2FA verify endpoint to derive user identity exclusively from the authentication token rather than the request body (GitHub issue #5743, release at https://github.com/baserow/baserow/releases/tag/2.3.3). As a compensating control where immediate upgrade is operationally blocked, administrators can restrict network access to the Baserow API endpoint (specifically /api/two-factor-auth/) to trusted internal networks only, reducing the attack surface to insider or already-compromised-network scenarios - note this does not eliminate the flaw and impacts legitimate remote 2FA usage. Disabling 2FA entirely is not recommended as a workaround since it removes a security control rather than fixing the underlying flaw. The vendor-released patch in 2.3.3 is the only confirmed fix.
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today