Description

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/data_sources/views.py are declared with a permission class that admits any caller, so a request carrying no credential reaches the handler. DataSourceService.dispatch_data_sources in backend/src/baserow/contrib/builder/data_sources/service.py then calls check_multiple_permissions 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 raise_exception to the same call.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-27T17:20:53.850Z",
  "pubdate": "2026-08-27T17:20:53.850Z",
  "executiveSummary": "Baserow version 2.3.1 and earlier contain a critical broken access control vulnerability in the Application Builder data source dispatching mechanism.\nThe vulnerability originates from a failure to enforce permission checks within the application's service layer, allowing unauthenticated users to access sensitive data.\nBy targeting the dispatch and record-name views, an attacker can bypass authentication entirely, as the API endpoints do not require valid credentials.\nThe flaw lies in the `DataSourceService.dispatch_data_sources` function, which fails to act upon the results returned by `check_multiple_permissions`.\nBecause the system executes these requests using the integration's own privileged credentials, an unauthenticated attacker can retrieve data source rows and fields.\nSince data source identifiers are small, sequential integers, they are highly susceptible to enumeration attacks.\nThis exposure poses a severe risk to data confidentiality, as unauthorized parties can exfiltrate information without any interaction with the intended access control policies.",
  "technicalDetails": "The vulnerability resides within the backend API architecture of Baserow's Application Builder, specifically in `backend/src/baserow/contrib/builder/api/data_sources/views.py` and `backend/src/baserow/contrib/builder/data_sources/service.py`.\nThe root cause is a failure in the permission enforcement logic. The API views are configured with a permissive permission class that allows any caller, regardless of authentication status, to invoke the handler. Once the request reaches the `DataSourceService.dispatch_data_sources` function, the application invokes `check_multiple_permissions` to validate user rights. However, the function does not pass the `raise_exception` parameter, nor does it programmatically handle the returned mapping of denied permissions.\nConsequently, when a permission check fails, the application simply ignores the denial and proceeds with the data source dispatch process. Because the operation is executed using the integration's internal service credentials rather than the caller's identity, the system performs the data retrieval with elevated privileges.\nThe exploitation flow is straightforward: 1) An unauthenticated attacker identifies a target data source identifier, which can be easily brute-forced or enumerated due to the predictable, small-integer format of these IDs. 2) The attacker sends an unauthenticated HTTP request to the vulnerable API endpoints (dispatch or record-name). 3) The request bypasses the initial view-level permission checks. 4) The service layer logic, failing to validate the permission result, proceeds to fetch the requested data using the integration's backend credentials. 5) The API returns the sensitive rows and fields associated with the requested data source to the unauthenticated attacker.\nThis vulnerability effectively renders the data source access control policy moot, exposing the entirety of the integrated data to any network-capable actor. The impact is a complete loss of confidentiality for the data source content. The vulnerability is mitigated in version 2.3.1, where the call to `check_multiple_permissions` is updated to include the `raise_exception` argument, ensuring that unauthorized attempts are properly aborted at the service layer."
}