CVE-2026-53644 in FOSSBilling
Summary
by MITRE • 07/07/2026
FOSSBilling is a free, open-source billing and client management system. Versions 0.5.3 through 0.7.2 allow authenticated clients to both read and reset API key service secrets for orders that are no longer in an `active` state (e.g., `suspended`, `canceled`). The root cause is missing order-state validation in two client API endpoints, despite an `isActive()` helper already existing in the `Serviceapikey` module and the frontend UI correctly gating access on `order.status == 'active'`. Version 0.8.0 contains a fix. Some workarounds are available. If the `Serviceapikey` module is not needed, uninstall it to remove the affected endpoints. One may also use a reverse proxy or WAF to restrict access to `/api/client/order/service` and `/api/client/serviceapikey/reset` based on application-level order-state logic.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/07/2026
This vulnerability exists within FOSSBilling, a widely-used open-source billing and client management platform that serves thousands of organizations worldwide. The issue stems from inadequate authorization controls in the API endpoints responsible for managing service secrets and API keys. Specifically, authenticated users can manipulate API key secrets for orders that have transitioned from active status to suspended or canceled states, creating a significant security risk in the system's access control mechanisms.
The technical flaw manifests through missing order-state validation within two critical client API endpoints: those handling order services and service key resets. Despite the existence of an `isActive()` helper function already implemented within the `Serviceapikey` module and proper frontend UI restrictions that correctly prevent access when `order.status != 'active'`, the backend API endpoints fail to enforce the same validation logic. This inconsistency creates a privilege escalation vector where authenticated users can bypass intended access controls by directly calling the API endpoints rather than relying on the UI layer for protection.
The operational impact of this vulnerability is substantial as it allows malicious actors or compromised legitimate users to potentially gain unauthorized access to systems and services that should no longer be accessible. When orders are suspended or canceled, they typically represent terminated services where continued access should be restricted. However, this vulnerability enables attackers to reset API secrets for these deactivated orders, potentially maintaining unauthorized access to underlying systems or services that depend on those keys. The vulnerability affects a broad range of versions from 0.5.3 through 0.7.2, indicating a prolonged period during which the system was vulnerable to exploitation.
The fix implemented in version 0.8.0 addresses this by properly enforcing order state validation within the affected API endpoints, ensuring that service secret operations can only occur on active orders. Organizations can implement several mitigations while awaiting or during the upgrade process. The most straightforward approach involves completely uninstalling the `Serviceapikey` module if it is not required for business operations, effectively removing the vulnerable endpoints from the system entirely. Alternatively, network-level protections such as reverse proxies or web application firewalls can be configured to inspect and filter API requests based on order status parameters before they reach the vulnerable endpoints, providing an additional layer of security control that aligns with defense-in-depth principles.
This vulnerability type corresponds to CWE-668 - "Exposure of Resource to Wrong Sphere" and reflects a classic authorization bypass issue where resources are exposed beyond their intended access scope. The attack pattern aligns with ATT&CK technique T1078.004 - "Valid Accounts: Cloud Accounts" as it exploits legitimate authenticated user sessions to perform unauthorized operations on deactivated services. The vulnerability demonstrates how seemingly minor oversights in API endpoint validation can create significant security weaknesses, particularly in billing systems where access control and resource management are critical for maintaining service integrity and preventing unauthorized access to potentially sensitive infrastructure components.