CVE-2026-43920
MediumCVSS 6.9Exploitation Probability (EPSS)
Low risk42th percentile — higher than 42% of all known CVEs
Summary
A vulnerability in FOSSBilling versions 0.5.4 through 0.7.2 allows an unauthenticated remote attacker to trigger the /run-patcher maintenance endpoint, which executes critical operations such as configuration file modifications, database schema changes, filesystem mutations, and cache clearing. The lack of authentication and CSRF validation enables denial-of-service attacks via a simple HTTP GET request.
Risk Assessment
The risk includes denial-of-service (DoS) attacks through repeated endpoint calls, leading to inconsistent database states, session invalidation, and system disruption. Certain patches, such as token regeneration for all admin and client accounts, are disruptive even when re-executed.
Recommendation
Immediately upgrade FOSSBilling to version 0.8.0, which contains the fix. Until then, block access to the /run-patcher endpoint at the firewall or web server level.
Original NVD description (English source)
FOSSBilling is a free, open-source billing and client management system. In versions 0.5.4 through 0.7.2, the /run-patcher maintenance endpoint in FOSSBilling was accessible without authentication, which allowed unauthenticated remote users to trigger update patch routines that modify configuration files, execute database schema changes, perform filesystem mutations, and clear caches. The /run-patcher endpoint executes privileged maintenance operations - configuration migrations, database patch execution (including ALTER TABLE, DROP TABLE, UPDATE statements), filesystem deletions and renames, and cache clearing - without requiring administrator authentication, CSRF validation, or CLI context. An unauthenticated remote attacker can trigger these operations by sending a simple HTTP GET request to /run-patcher, which can be abused for denial-of-service attacks. Certain patches (e.g., batch token regeneration for all admin and client accounts in patch 53, and session invalidation) are disruptive even when re-executed against an already-patched instance. Repeated or concurrent requests may also cause inconsistent database state. This issue has been fixed in version 0.8.0.