CVE-2026-82245 in Budibase
Summary
by MITRE • 08/28/2026
Budibase before 3.41.3 fails to enforce role-based authorization on license management endpoints, allowing any authenticated user to delete license keys or manipulate offline tokens. Attackers with basic user privileges can access /api/global/license/* endpoints to disable premium features and downgrade deployments for all users.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in Budibase versions prior to 3.41.3 represents a critical failure in role-based access control within the application's license management subsystem. This flaw specifically affects the API endpoints responsible for handling global license configurations, namely those under the /api/global/license/ path. In a properly secured enterprise environment, operations that modify licensing terms or deactivate premium features are strictly reserved for administrators with elevated privileges due to their direct impact on service availability and compliance status. However, in this vulnerable iteration, the server fails to validate whether the authenticated user possesses the necessary administrative rights before processing requests intended to delete license keys or manipulate offline tokens. This oversight allows any individual who has successfully authenticated to the application, regardless of their assigned role level, to execute these destructive actions.
From a technical perspective, the root cause lies in the middleware or route handler logic that governs access to the global configuration endpoints. The system appears to rely solely on authentication rather than authorization checks for these specific routes. When an attacker with basic user privileges sends a request to delete a license key or alter offline token settings, the server processes it without verifying if the requester holds admin-level permissions. This lack of enforcement means that the security boundary between standard users and administrators is effectively bypassed at this layer. The ability to manipulate offline tokens further exacerbates the risk, as these tokens are often used for authentication in headless or automated scenarios, potentially allowing an attacker to maintain persistent access even if their primary account credentials are revoked.
The operational impact of this vulnerability is severe, primarily because it enables a denial-of-service condition against premium features and can lead to significant financial and compliance repercussions. By deleting license keys, an attacker with minimal privileges can effectively disable all premium functionalities for the entire organization. This action forces the deployment into a restricted mode that may lack critical tools required for business operations, leading to productivity losses and potential contract violations if service level agreements depend on those features. Furthermore, the manipulation of offline tokens could compromise the integrity of automated workflows or integrations that rely on these credentials, potentially causing data synchronization failures or unauthorized access through secondary channels.
This vulnerability aligns with CWE-269, which describes Improper Privilege Control, as it involves a failure to enforce proper authorization levels for sensitive operations. It also maps to MITRE ATT&CK technique T1484.001, Domain Policy Modification, specifically under the subcategory of Group Policy Discovery or modification if interpreted broadly within an identity management context, though more accurately it fits T1531 Account Access Removal via disabling accounts or features that restrict access. The scenario illustrates how a seemingly minor configuration endpoint can become a vector for significant disruption when privilege checks are omitted.
To mitigate this risk, organizations running Budibase versions prior to 3.41.3 should upgrade immediately to version 3.41.3 or later where these authorization controls have been corrected. In the interim, if upgrading is not feasible, administrators should restrict network access to the license management endpoints using firewall rules or reverse proxy configurations that limit visibility to trusted administrative IP ranges only. Additionally, implementing strict monitoring and alerting on API calls to /api/global/license/* can help detect unauthorized attempts by non-admin users in real-time. Regular audits of user roles and permissions are also recommended to ensure that no unnecessary privileges have been granted to standard accounts, thereby reducing the attack surface for such authorization bypasses.