CVE-2026-111056 in FOSSBilling
Summary
by MITRE • 10/19/2026
FOSSBilling is an open source billing and client-management platform. From 0.1.0 until 0.8.7, the unauthenticated POST /api/guest/client/create endpoint reveals whether a submitted email belongs to a registered client because guest signup returns a distinct unredacted error when the submitted email already exists. The trigger is an unauthenticated request to POST /api/guest/client/create with a target email address. An attacker can compare the guest-signup response for a target email to determine whether the email belongs to an existing FOSSBilling client. Box\Mod\Client\Api\Guest::create returns the error after Client\Service::clientAlreadyExists finds a matching record, and the API response exposes that exception message without redaction. This issue is fixed in version 0.8.7.
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 serves as an open-source billing and client-management platform widely used by hosting providers and digital service companies to manage subscriptions, invoices, and customer data. A significant information disclosure vulnerability exists within the application's API layer, specifically affecting versions from 0.1.0 up through 0.8.7. This flaw resides in the unauthenticated endpoint POST /api/guest/client/create, which is designed to allow new users to register for services without prior authentication. The core technical deficiency lies in how the backend logic handles duplicate registration attempts and subsequently formats the API response returned to the client.
The vulnerability stems from inconsistent error handling within the Box\Mod\Client\Api\Guest::create method. When an unauthenticated actor submits a POST request with an email address that is already registered in the database, the underlying Client\Service::clientAlreadyExists function detects the duplicate record and triggers an exception. Instead of returning a generic or redacted message such as registration failed due to server error, the application exposes the specific internal exception message indicating that the client already exists. This distinct unredacted response creates a clear signal difference between successful registrations for new emails and rejected attempts for existing ones.
This behavior enables attackers to perform email enumeration attacks against FOSSBilling instances without needing valid credentials or bypassing any access controls. By systematically submitting various email addresses to this endpoint, an adversary can compare the HTTP responses to determine with high accuracy whether a specific email address is associated with an active client account in the system. This capability effectively allows for the mapping of user bases and identification of potential targets based on their registered contact information.
The operational impact of this vulnerability extends beyond simple data leakage. Email enumeration serves as a critical reconnaissance phase for subsequent attacks, including targeted phishing campaigns, credential stuffing, or social engineering efforts. Attackers can use the confirmed list of valid email addresses to craft more convincing malicious communications that reference specific services or account details known to exist within the platform. This significantly lowers the barrier for initiating further compromise attempts against individual users or administrative accounts associated with those emails.
From a classification perspective, this vulnerability aligns with CWE-203: Observable Discrepancy and CWE-209: Generation of Error Message Containing Sensitive Information. It also maps to MITRE ATT&CK technique T1589.001: Gather Victim Identity Information - Email Addresses, which is commonly used in the initial reconnaissance phase of cyber attacks. The lack of uniform error responses allows attackers to infer sensitive information about user existence without direct access to protected data stores.
To mitigate this risk, organizations running FOSSBilling must upgrade immediately to version 0.8.7 or later, where the issue has been resolved by ensuring consistent response formatting regardless of whether an email is new or existing. For environments that cannot yet patch due to dependency constraints, implementing a reverse proxy or web application firewall rule can help normalize API responses before they reach the client. Additionally, developers should enforce generic error messages for all authentication and registration failures to prevent information leakage through side channels such as response content differences.