Description

Budibase server before 3.45.0 contains a cross-tenant information disclosure vulnerability in the GET /api/applications/:appId/appPackage endpoint that allows authenticated users to read another tenant's application metadata and source code. Attackers can supply a victim tenant's app id to retrieve sensitive application details including navigation structure, role names, internal screen URLs, JavaScript snippets, and user identifiers without authorization checks.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-26T14:16:53.280Z",
  "pubdate": "2026-09-26T14:16:53.280Z",
  "executiveSummary": "Budibase server versions prior to 3.45.0 are susceptible to a critical cross-tenant information disclosure vulnerability within the application packaging API.\nThe vulnerability allows authenticated users to bypass tenant isolation boundaries, enabling unauthorized retrieval of sensitive application metadata and source code belonging to other tenants.\nThis flaw involves a Broken Object Level Authorization (BOLA) failure on the GET /api/applications/:appId/appPackage endpoint.\nBy manipulating the 'appId' parameter, a malicious actor can exfiltrate proprietary business logic, internal navigation structures, JavaScript snippets, role definitions, and user identifiers.\nThe risk implication is significant, as it facilitates unauthorized reconnaissance, intellectual property theft, and potential privilege escalation by mapping the internal security posture of a victim tenant.\nExploitation requires an authenticated session within the Budibase environment, meaning attackers do not need administrative privileges on the target tenant, only valid access to the platform.",
  "technicalDetails": "The root cause of the vulnerability resides in a lack of proper authorization checks at the API controller level for the GET /api/applications/:appId/appPackage endpoint in Budibase versions before 3.45.0.\nThe application fails to validate whether the authenticated user possesses the appropriate permissions or membership within the tenant associated with the requested 'appId'.\nIn a multi-tenant architecture, the backend is expected to enforce strict object-level access controls to ensure that an 'appId' context is restricted to the scope of the requesting user's organization.\nThe attack flow proceeds as follows: First, the attacker initiates an authenticated session within the platform. Second, the attacker identifies a target 'appId' belonging to a different, unauthorized tenant. Third, the attacker issues a GET request to '/api/applications/:appId/appPackage'.\nBecause the server-side code does not verify the relationship between the authenticated user's session token and the resource identified by the 'appId', it processes the request and serializes the application package data.\nThe returned JSON payload contains the complete metadata of the target application, including but not limited to the navigation tree, sensitive JavaScript logic used for backend automation or frontend UI manipulation, and internal screen URLs.\nFurthermore, the disclosure includes role names and user identifiers, providing the attacker with a roadmap of the victim tenant's organizational structure.\nThis exposure of internal JavaScript snippets is particularly critical, as it may contain hardcoded secrets, API endpoints, or logic patterns that could lead to further exploitation or unauthorized data access.\nThe vulnerability is classified as a Broken Object Level Authorization (BOLA) issue, as it bypasses vertical and horizontal access controls by relying on user-supplied input to retrieve data without verifying resource ownership at the data access layer.\nThe attack is performed over standard HTTPS/REST protocols and does not require complex payloads, merely a correctly formatted request targeting an external resource identifier that has been identified via enumeration or side-channel discovery."
}