FOSSBilling CVE-2026-53642
MEDIUMSeverity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/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
Network-accessible web application, low-privilege authenticated client account required, no user interaction; confidentiality limited to financial data read with no integrity or availability impact.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
1DescriptionCVE.org
FOSSBilling is a free, open-source billing and client management system. In versions 0.5.6 through 0.7.2, when the "Require Email Confirmation" setting is enabled, a logged-in client with an unverified email address (email_approved = 0) can access all client-area pages (e.g. /client/balance, /client/order/list, /client/invoice) and read real account data, including wallet balances and transaction history. The API-side enforcement correctly restricts unverified clients to only profile-related endpoints, but the page-side enforcement is overly permissive, allowing any request whose path starts with /client. Version 0.8.0 contains a fix. No known workarounds that don't involve modifying the source code are available.
AnalysisAI
Incorrect authorization in FOSSBilling versions 0.5.6 through 0.7.2 allows authenticated clients with unverified email addresses to bypass the 'Require Email Confirmation' access control gate and read sensitive financial account data - including wallet balances and full transaction history - across all client-area pages. The application maintains two separate authorization layers: an API-level guard that correctly restricts unverified clients, and a page-level routing guard that is overly permissive, admitting any request whose URL path begins with /client, creating an exploitable enforcement gap. No public exploit has been identified at time of analysis; the CVSS 4.0 score of 5.3 reflects a realistic but bounded confidentiality impact gated behind prior authentication.
Technical ContextAI
FOSSBilling is a PHP-based open-source billing and client management platform commonly used by small hosting providers and digital service businesses. The vulnerability maps to CWE-863 (Incorrect Authorization): two authorization enforcement points exist within the application - an API-layer guard that correctly enforces email verification status and restricts unverified accounts to only profile-related endpoints, and a page-layer routing guard that is insufficiently restrictive, permitting access to any URL whose path begins with /client. This split-enforcement architecture means the business-logic gate (email verification) is bypassed at the presentation layer. The affected codebase spans versions 0.5.6 through 0.7.2. The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N confirms network-accessible exploitation by a low-privileged authenticated user with no special attack requirements and a limited confidentiality impact on the vulnerable system.
Affected ProductsAI
FOSSBilling versions 0.5.6 through 0.7.2 are affected when the 'Require Email Confirmation' admin configuration setting is enabled. Version 0.8.0 is confirmed as the fixed release. Full vendor advisory and fix details are available at the GitHub Security Advisory GHSA-7v47-rh46-w923: https://github.com/FOSSBilling/FOSSBilling/security/advisories/GHSA-7v47-rh46-w923.
RemediationAI
Upgrade FOSSBilling to version 0.8.0, which corrects the page-level authorization enforcement to match the existing API-layer restriction. The vendor advisory is available at https://github.com/FOSSBilling/FOSSBilling/security/advisories/GHSA-7v47-rh46-w923. The vendor explicitly states no known workarounds exist that do not require modifying source code. If an immediate upgrade is not feasible, operators may consider temporarily disabling the 'Require Email Confirmation' feature entirely - this eliminates the vulnerable code path but removes email verification enforcement, meaning unverified accounts gain normal client access. Alternatively, a targeted source code patch to the page-level routing guard to replicate the API-layer verification check would close the gap, but any custom modification should be reviewed and tested before deployment in production.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today