CVE-2026-111046 in FOSSBilling
Summary
by MITRE • 10/19/2026
FOSSBilling is an open source billing and client-management platform. From 0.8.4 until 0.8.6, hasManagePermission fails open for inactive non-core modules because its early return on !isExtensionActive skips the module-access and manage_settings checks. A low-privileged staff account with module-level extension access targets a deactivated non-core module through extension/config_get or extension/config_save. The account can call api/admin/extension/config_get or api/admin/extension/config_save for a deactivated non-core module to read decrypted retained extension secrets and overwrite stored extension configuration. The getConfig function returns the decrypted stored configuration despite the module's inactive state. This residual path remained after the earlier CVE-2026-62962 authorization fix. This issue is fixed in version 0.8.6.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/19/2026
FOSSBilling, an open-source billing and client-management platform utilized by hosting providers and digital service agencies, contains a critical access control vulnerability affecting versions from 0.8.4 through 0.8.5. This flaw stems from a logic error within the hasManagePermission function, which is responsible for verifying whether a user possesses the necessary privileges to modify or manage specific modules. The core technical deficiency lies in an early return statement that checks if an extension is active using the !isExtensionActive condition. When this check evaluates to true because the module is inactive, the function immediately returns without proceeding to perform essential authorization checks such as verifying module-access rights and validate_manage_settings permissions. This design oversight creates a bypass mechanism where the security controls intended for managing extensions are effectively disabled based solely on the operational state of the module rather than the user's actual privileges.
The impact of this vulnerability is significant, particularly regarding data confidentiality and integrity within the platform. A low-privileged staff account that has been granted basic module-level extension access can exploit this flaw by targeting a deactivated non-core module. By invoking specific API endpoints such as api/admin/extension/config_get or api/admin/extension/config_save, an attacker can interact with modules that are supposed to be inaccessible due to their inactive status. The getConfig function returns the decrypted stored configuration for these modules despite their inactive state. This allows unauthorized users to read sensitive extension secrets that have been retained in plaintext within the database. Furthermore, the ability to call config_save enables the overwriting of stored extension configurations, potentially leading to further compromise or disruption of service depending on how those configurations are utilized by other system components.
This vulnerability represents a residual path from an earlier security fix associated with CVE-2026-62962. While previous patches addressed certain authorization bypasses, they failed to account for the specific interaction between inactive modules and permission checks in this particular code path. The issue highlights the importance of ensuring that all entry points into sensitive configuration data are consistently protected regardless of module state. From a classification perspective, this flaw aligns with CWE-284 Improper Access Control, as it involves unauthorized access to restricted resources due to flawed logic in authorization routines. Additionally, it relates to CWE-601 URL Redirection to Untrusted Site via User-Controlled Key if the configuration changes lead to redirect-based attacks, and falls under MITRE ATT&CK technique T1530 Data from Cloud Storage Object or T1222 File and Directory Permissions Modification depending on the specific exploitation vector used by an attacker.
The vulnerability was resolved in version 0.8.6 of FOSSBilling through a correction to the hasManagePermission logic, ensuring that authorization checks are performed even when extensions are inactive. To mitigate this risk for organizations still running affected versions, immediate upgrade to version 0.8.6 or later is strongly recommended. In cases where upgrading is not immediately feasible, administrators should review staff account permissions and restrict module-level extension access to only those users who absolutely require it. Additionally, auditing the database for plaintext storage of sensitive credentials in extension configurations can help assess potential exposure from past exploitation attempts. Regular security audits focusing on authorization logic across all module states are essential to prevent similar residual vulnerabilities from persisting after partial patches are applied.