Which versions of FOSSBilling are affected by CVE-2026-53644?

FOSSBilling versions 0.5.3 through 0.7.2 allow any authenticated user to access API key credentials for inactive orders, exposing high-value secrets that could enable unauthorized system access.

How to fix or mitigate CVE-2026-53644?

Within 24 hours: Identify all FOSSBilling instances running versions 0.5.3-0.7.2; isolate network access where possible; audit API key usage logs for suspicious activity. Within 7 days: Assess the security implications and rotate all API keys that may have been exposed. Within 30 days: Upgrade all affected instances to FOSSBilling version 0.8.0 and verify the fix is effective.

FOSSBilling CVE-2026-53644

Q: What is the CVSS score of CVE-2026-53644?

CVE-2026-53644 has a CVSS 4.0 base score of 8.6 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

HIGH

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-07-06 security-advisories@github.com

Authentication Bypass

8.6

CVSS 4.0 · Vendor: github

Severity by source

Vendor (github) PRIMARY

8.6 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.1 HIGH

Authenticated client account gives PR:L; endpoints are network-reachable with low complexity; reading secrets is C:H and resetting them is I:H; no availability impact so A:N.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jul 06, 2026 - 23:34 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Broken object-level authorization in FOSSBilling 0.5.3 through 0.7.2 lets an authenticated client read and reset API key service secrets belonging to orders that are no longer active, such as suspended or canceled orders. Two client API endpoints skip the order-state check that the frontend UI and the module's own isActive() helper otherwise enforce, exposing high-value credentials to any logged-in customer for their non-active services. There is no public exploit identified at time of analysis, and the flaw is fixed in version 0.8.0.

Technical ContextAI

FOSSBilling is a PHP-based open-source billing and client management platform, and the weakness lives in its Serviceapikey module, which provisions and manages per-order API key secrets consumed via the /api/client/order/service and /api/client/serviceapikey/reset endpoints. This is a classic CWE-639 (Authorization Bypass Through User-Controlled Key) issue: authorization is enforced at the presentation layer (the UI gates on order.status == 'active') but the two API endpoints fail to re-validate order state server-side, even though an isActive() helper already exists in the same module. Because the API trusts the client-supplied order reference without confirming the order is active, a customer can operate on secrets for services they nominally still own but which the business logic treats as inactive.

Affected ProductsAI

FOSSBilling, the free open-source billing and client management system, is affected in all versions from 0.5.3 through 0.7.2 inclusive; version 0.8.0 contains the fix. The vulnerable code is the Serviceapikey module reachable via the /api/client/order/service and /api/client/serviceapikey/reset endpoints. No CPE string was provided in the input. The authoritative reference is the vendor GitHub Security Advisory at https://github.com/FOSSBilling/FOSSBilling/security/advisories/GHSA-qf6j-vq68-qmfh.

RemediationAI

Upgrade to FOSSBilling 0.8.0, which adds the missing order-state validation to both client API endpoints (Vendor-released patch: 0.8.0). If you cannot upgrade immediately and do not use the Serviceapikey feature, uninstall the Serviceapikey module to remove the affected endpoints entirely, which cleanly eliminates the attack surface but disables API key provisioning for all customers. Alternatively, place a reverse proxy or WAF in front of the application to restrict access to /api/client/order/service and /api/client/serviceapikey/reset using application-level order-state logic; this preserves the feature for active orders but requires the proxy to reliably determine order status, which is error-prone and may block legitimate requests if the logic drifts from the application. After patching, rotate any API key secrets that may have been exposed. See the advisory at https://github.com/FOSSBilling/FOSSBilling/security/advisories/GHSA-qf6j-vq68-qmfh.