CVE-2026-81335: Baserow before 2.3.1 Unauthenticated Data Disclosure via Discarded Permission Check on Builder Data Sources
Baserow dispatches an Application Builder data source without acting on the result of its permission check. The dispatch and record-name views in backend/src/baserow/contrib/builder/api/datasources/views.py are declared with a permission class that admits any caller, so a request carrying no credential reaches the handler. DataSourceService.dispatchdatasources in backend/src/baserow/contrib/builder/datasources/service.py then calls checkmultiplepermissions without asking it to raise, and neither stores nor examines the mapping of denials it returns, so a denied check leaves execution to continue and the data source is dispatched whatever the caller's identity. The dispatch runs with the integration's own credentials, so an unauthenticated request naming a data source receives the rows and fields that source reads. Identifiers are small integers and can be enumerated. Version 2.3.1 passes raiseexception to the same call.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
baserowto a version that resolves this vulnerability.Fixed in 2.3.1 - Configuration
Update the dispatch and record-name views so the permission class does not admit any caller, ensuring requests without valid credentials cannot reach the handler.
Baserow builder API views (backend/src/baserow/contrib/builder/api/data_sources/views.py) permission class = restricted to authenticated callers (not “admits any caller”)
Event History
Frequently Asked Questions
Who is exposed to this issue?
Baserow instances before 2.3.1 with Application Builder data sources are exposed. The affected dispatch and record-name endpoints admit unauthenticated callers, so no user account or credential is required.
What does an attacker need to exploit it?
An attacker only needs to send requests identifying a data source. Data-source identifiers are small integers and can be enumerated, making discovery practical.
What data can be disclosed?
The vulnerable dispatch executes using the integration's own credentials and returns the rows and fields read by the named data source. The disclosed scope therefore depends on what each configured integration and data source can access.
Does this require a permissive user configuration?
No. The permission check may deny the caller, but its denial result is discarded and processing continues. An unauthenticated request can therefore dispatch the data source despite the denied check.
What change fixes the issue?
Version 2.3.1 changes the permission-check call to pass raise_exception, preventing dispatch from continuing when permission is denied.