CVE-2026-43926
Password Reset Token Oracle in FOSSBilling
Publication date: 2026-06-04
Last updated on: 2026-06-04
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| fossbilling | fossbilling | to 0.7.2 (inc) |
| fossbilling | fossbilling | 0.8.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-307 | The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame. |
| CWE-204 | The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in FOSSBilling prior to version 0.8.0 allows attackers to probe password reset confirmation endpoints without rate limiting, potentially enabling unlimited token guessing attempts.
However, the exploitability is mitigated by strong token entropy (256 bits) and short token expiration (15 minutes), and the vulnerability is classified as low severity with no direct impact on confidentiality, integrity, or availability.
There is no explicit information provided about how this vulnerability affects compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
The vulnerability in FOSSBilling versions prior to 0.8.0 involves the password reset confirmation endpoint `/client/reset-password-confirm/:hash`. This endpoint is handled by a non-API controller and is not protected by the system's rate limiter, which only applies to `/api/*` routes.
Because of this, an attacker can send unlimited requests to this endpoint without any per-IP request limiting, attempt counting, or lockout mechanisms. The endpoint acts as an oracle by returning different HTTP responses for valid tokens (HTTP 200) versus invalid tokens (HTTP 302 redirect), allowing attackers to probe for valid reset tokens.
Although the exploitability is reduced by the use of strong token generation (256 bits of entropy) and short token expiration (15 minutes), the vulnerability also affects other authentication routes like `/staff/email/:hash` and `/client/confirm-email/:hash`.
How can this vulnerability impact me? :
This vulnerability allows an attacker to attempt unlimited guesses of password reset tokens without any throttling or lockout, potentially enabling them to discover valid tokens.
However, the practical risk is mitigated by the high entropy of the tokens (256 bits) and their short expiration time (15 minutes), making successful exploitation difficult.
If exploited, an attacker could potentially reset user passwords or confirm email addresses without authorization, which could lead to unauthorized access to user accounts.
Mitigations include upgrading to FOSSBilling version 0.8.0 or applying rate limiting via reverse proxies or WAFs to the affected endpoints.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring requests to the password reset confirmation endpoint `/client/reset-password-confirm/:hash` and related endpoints such as `/staff/email/:hash` and `/client/confirm-email/:hash` for unusual or excessive access patterns.
Because the endpoint returns distinct HTTP responses for valid (HTTP 200) and invalid (HTTP 302 redirect) tokens, you can detect probing attempts by analyzing web server logs for a high volume of requests to these endpoints without rate limiting.
Suggested commands to detect such activity include using tools like `grep` or `awk` on your web server logs to filter requests to these paths and count the number of requests per IP address.
- Example command to find requests to the vulnerable endpoint in Apache logs: `grep '/client/reset-password-confirm/' /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -nr`
- Similarly, for Nginx logs: `grep '/client/reset-password-confirm/' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr`
- Look for IP addresses with a high number of requests to these endpoints, which may indicate probing or brute force attempts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include configuring a reverse proxy or web application firewall (WAF) to apply per-IP rate limiting on the vulnerable endpoints `/client/reset-password-confirm/*`, `/staff/email/*`, and `/client/confirm-email/*`.
This will help prevent attackers from submitting unlimited token guesses by limiting the number of requests allowed from a single IP address within a certain time frame.
Additionally, upgrading FOSSBilling to version 0.8.0 or later is strongly recommended, as this version includes a fix for the vulnerability along with other security improvements.
Before upgrading, review the release notes for potential breaking changes and ensure you have a backup of your installation.