FOSSBilling's password reset confirmation endpoint lacks rate limiting, turning the endpoint into an oracle that distinguishes valid reset tokens from invalid ones by returning HTTP 200 for a valid hash and HTTP 302 for an invalid one. An attacker can submit unlimited guesses without per‑IP request limiting, enabling brute‑force enumeration of active password‑reset tokens. While the token generator employs SHA‑256 over 32 random bytes yielding 256 bits of entropy and the tokens expire after 15 minutes or are removed after use, the absence of rate limiting still permits excessive probing, which can facilitate account takeover or reveal which emails have active reset requests. This flaw meets CWE‑307 (Improper Restriction of Excessive Authentication Attempts) and CWE‑204 (Information Exposure Through Error Messages).

The vulnerability affects all public installations of FOSSBilling that used a version earlier than 0.8.0, including the community edition. No specific sub‑version numbers are mentioned, but any release derived from the code base before the 0.8.0 release is subject to the lack of rate limiting on the /client/reset-password-confirm/:hash endpoint, as well as the analogous /staff/email/:hash and /client/confirm-email/:hash routes.

The CVSS score of 6.3 indicates a medium‑severity weakness. Because the EPSS score is unavailable, exploitation probability cannot be quantified, but the flaw remains relevant as attackers can observe response differences. The issue is not listed in the CISA KEV catalog, suggesting it is not currently a widely reported exploited vulnerability, yet the design flaw gives an attacker a convenient oracle that can be used for token enumeration. The attack vector is primarily remote, via HTTP requests to the affected endpoints, and requires no privileged access prior to initiating guesses. Mitigation is straightforward through application of the 0.8.0 update or by implementing external rate limiting.