FOSSBilling EUVD-2026-104418

No special conditions - remote unauthenticated exploitation against default configurations of FOSSBilling versions 0.1.0 through 0.8.6, since the POST /api/guest/client/create guest-signup endpoint is publicly reachable. Exploitation requires that guest registration is enabled (the code throws 'New registrations are temporarily disabled' when config disable_signup is set, which would suppress the distinct error path). Before 0.8.7 there was no per-email rate limiting, so mass enumeration was unthrottled; the fix adds a client_signup_email fixed-window limit of 5 attempts per hour, which is the primary limiting factor post-patch. Impact is bounded to confirming email-to-client membership (no credential, account, or data compromise).

This is a genuine but low-severity information-disclosure issue, not a high-priority emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) correctly reflects that any remote, unauthenticated attacker can reach the vulnerable POST /api/guest/client/create endpoint with no special conditions, which raises the base score to 6.9; however, the only impact metric set is VC:L (low confidentiality) with VI:N/VA:N, meaning the real-world consequence is limited to confirming whether a given email is a registered FOSSBilling client - an enumeration/privacy leak, not code execution, data theft, or integrity loss. No EPSS score was supplied in the input, and the CVE is not listed in CISA KEV; no public exploit code is referenced either, though a vendor security advisory (GHSA-x4mh-g4pc-wfc5), the fixing PR #4234, and the patch commit are all public, so a working exploit is trivial to reconstruct from the diff. The signals are consistent rather than conflicting: a network-reachable, low-complexity, unauthenticated flaw with low technical impact. Treat this as a routine hardening fix to schedule in normal patch cycles, prioritized higher only for internet-facing instances where client email confidentiality (e.g. anonymity of customers) matters.

A remote unauthenticated attacker sends POST requests to /api/guest/client/create supplying candidate email addresses and observes that an already-registered email returns a distinct, unredacted 'client already exists' error versus the normal signup flow. By iterating over a list of target emails, the attacker builds a confirmed list of valid FOSSBilling customers. No public exploit is referenced, but the fixing PR diff fully reveals the behavior, making reconstruction trivial.