CVE-2026-81335 in Baserow
Summary
by MITRE • 08/27/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability in Baserow represents a critical authentication bypass within its Application Builder feature, specifically affecting how data sources are accessed via API endpoints. The core technical flaw lies in the implementation of permission checks for the dispatch and record-name views located in the backend source code. These views are configured with a permission class that effectively admits any caller, allowing unauthenticated requests to reach the handler logic without proper credential verification. This initial failure creates an entry point where external actors can interact with internal data structures without providing valid authentication tokens or session identifiers.
The operational impact is exacerbated by how the backend service handles authorization decisions. The DataSourceService.dispatch_data_sources method invokes check_multiple_permissions but explicitly omits the raise_exception parameter, which would normally halt execution if a permission denial occurs. Instead of enforcing access control policies, the system ignores the mapping of denials returned by this function. Consequently, even when the underlying security logic determines that a user lacks sufficient privileges to view specific data sources, the application continues processing the request and dispatches the requested information regardless of the outcome. This design error effectively nullifies the intended role-based access controls for these endpoints.
From an attacker's perspective, this flaw allows any individual with network connectivity to enumerate and extract sensitive business intelligence stored within connected integrations. Since data source identifiers are implemented as small integers, they can be trivially enumerated through simple iteration scripts. An unauthenticated actor can systematically probe various identifier values to discover valid data sources. Once a valid source is identified, the attacker receives full access to the rows and fields that the integration reads from external services such as databases or third-party APIs. This exposure potentially leads to significant confidentiality breaches, including the leakage of customer records, financial data, or proprietary operational metrics depending on what integrations are configured in the affected Baserow instance.
This vulnerability aligns with CWE-287, which describes Improper Authentication, and specifically relates to CWE-306, Missing Authentication for Critical Function. In terms of offensive security frameworks, this behavior maps to ATT&CK technique T1505.003, Server Software Component: Web Components, where an attacker exploits a misconfigured component to gain unauthorized access. The lack of proper authorization enforcement also touches upon CWE-862, Missing Authorization, as the system fails to verify that the authenticated or unauthenticated user has permission for the specific resource being accessed.
Mitigation strategies must focus on correcting the logic flow within the data source dispatch mechanism. Developers should ensure that check_multiple_permissions is called with raise_exception set to true so that any denial of access immediately terminates the request and returns an appropriate HTTP 403 Forbidden response rather than proceeding with data retrieval. Additionally, the permission classes for these views must be reviewed to ensure they enforce strict authentication requirements before allowing entry into the handler logic. For organizations currently running versions prior to 2.3.1, upgrading to version 2.3.1 or later is essential as this release corrects the raise_exception parameter usage. Until an upgrade can be performed, network-level access controls such as firewalls should restrict API endpoint exposure to known internal IP ranges if possible, and monitoring for unusual enumeration patterns against data source identifiers can help detect active exploitation attempts.