Baserow EUVD-2026-105159

Requires a valid authenticated Baserow account of any privilege level (CVSS PR:L) - exploitation is not possible unauthenticated, which is the primary limiting factor and makes multi-tenant instances with open/self-service signup the highest-risk deployments. No special configuration is needed: the missing permission check in the unique_row_values endpoint (backend/.../api/fields/views.py) affects default behavior in all versions before 2.3.0. Further limits on impact: the attacker must know or brute-force valid sequential field IDs, and each successful call returns only up to 100 distinct unique cell values per field (not full rows, records, or credentials), bounding the volume of data exfiltrated per request.

This is a moderate-severity information-disclosure flaw (CWE-639, missing authorization) best treated as a real but bounded issue rather than an emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L) is internally consistent with the description: network-reachable, low complexity, but requires an authenticated account (PR:L) and yields only low confidentiality impact with no integrity or availability impact. No EPSS score, no CISA KEV listing, and no public POC were provided in the intelligence, so there is no signal of active or widespread exploitation - exploitation status is 'no public exploit identified at time of analysis.' The 5.3 score is credible: the ceiling on harm is capped because only unique cell values (max 100 per field) are leaked, not full records or credentials. The source-code evidence (added CoreHandler permission check plus a regression test asserting ERROR_USER_NOT_IN_GROUP for non-members) confirms the root cause and the fix. The main caveat: any authenticated user in a multi-tenant Baserow deployment can read data across workspace boundaries, which is a meaningful confidentiality/tenant-isolation breach for SaaS or shared-hosting operators even though the raw CVSS is only medium. Prioritize patching for multi-tenant/public-signup instances; single-tenant internal deployments carry lower practical risk.

An attacker registers or already holds any low-privilege Baserow account, then calls the unique_row_values API endpoint while iterating sequential field IDs belonging to tables in workspaces they are not a member of. Because the pre-2.3.0 endpoint never checked workspace membership, the server returns up to 100 distinct cell values per field, letting the attacker harvest sensitive data from other tenants. No public exploit code was identified, but the attack is trivially scriptable given low attack complexity.