CVE-2026-53646 in FOSSBilling
Summary
by MITRE • 07/07/2026
FOSSBilling is a free, open-source billing and client management system. In versions 0.5.6 through 0.7.2, when a `ClientPasswordReset` record already exists for a client (from a previous unexpired reset request), subsequent calls to the `reset_password` guest API endpoint reuse the existing token instead of generating a new one. The 15-minute validity window is anchored to the first request's `created_at` timestamp, not the time of the most recent email. An attacker who obtained the original reset link remains able to use it even after the victim requests a new reset, because the original token is never invalidated or rotated. Version 0.8.0 patches the issue. Some workarounds are available. Configure a reverse proxy (e.g., Nginx, Apache, Cloudflare) to apply per-IP rate limiting to the `/client/reset-password` endpoint to minimize the window of opportunity, and/or manually clear expired `client_password_reset` records from the database after a client reports a suspected compromise.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/07/2026
This vulnerability exists within FOSSBilling's password reset mechanism where the system fails to properly handle concurrent reset requests for the same client account. The flaw stems from improper token management where existing password reset tokens are reused rather than being rotated when new reset requests are made, creating a persistent security weakness that allows attackers to exploit time-based vulnerabilities in the authentication flow. The vulnerability is classified as a weakness in session management and authentication mechanisms, aligning with CWE-613 which addresses "Insufficient Session Expiration" and CWE-306 which covers "Missing Authentication for Critical Function". This represents a significant risk to user account security as it undermines the fundamental principle of time-bound authentication tokens.
The technical implementation flaw occurs at the API endpoint level where the reset_password guest API does not properly validate whether an existing token should be invalidated when a new request is made. The system maintains a fixed 15-minute validity window anchored to the initial request timestamp rather than implementing proper token rotation or invalidation mechanisms. This design choice allows attackers to leverage stolen tokens even after legitimate users have requested new password resets, effectively extending the exploitation window beyond the intended security parameters. The vulnerability also demonstrates poor access control implementation since it fails to properly enforce the principle of least privilege in authentication flows.
The operational impact of this vulnerability is significant as it creates a persistent attack surface where compromised reset links can be reused indefinitely until manual cleanup occurs or the system is updated. Attackers can exploit this weakness by obtaining legitimate password reset tokens through various means such as phishing, credential theft, or network interception, then continue using these tokens even after victims have requested new resets. This undermines user trust in the security of the billing system and creates potential for unauthorized account access and financial fraud. The vulnerability also affects compliance with security standards such as those outlined in the NIST SP 800-63B guidelines for authentication and the OWASP Authentication Cheat Sheet which emphasizes proper token lifecycle management.
Mitigation strategies should focus on both immediate defensive measures and long-term architectural improvements. The most effective approach involves upgrading to version 0.8.0 which properly addresses the token rotation issue through automatic invalidation of previous tokens when new requests are made. Organizations can implement temporary workarounds such as configuring reverse proxies with per-IP rate limiting to restrict the number of reset requests from individual IP addresses, reducing the window of opportunity for attackers. Additionally, manual database cleanup procedures should be established to regularly purge expired client_password_reset records, ensuring that compromised tokens cannot be reused indefinitely. These measures align with ATT&CK technique T1566 which covers credential harvesting through social engineering and T1078 which addresses legitimate credentials usage. The implementation of proper token lifecycle management including automatic invalidation and rotation mechanisms should become a standard security practice for all authentication systems to prevent similar vulnerabilities from occurring in the future.