CVE-2026-53646: FOSSBilling Auth Bypass Vulnerability

CVE-2026-53646 Overview

FOSSBilling, a free and open-source billing and client management system, contains a password reset token reuse vulnerability in versions 0.5.6 through 0.7.2. When a ClientPasswordReset record already exists for a client from a prior unexpired 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 rather than the most recent email. An attacker who obtained the original reset link can continue using it even after the victim requests a new reset. Version 0.8.0 patches the issue. The weakness is tracked as CWE-640: Weak Password Recovery Mechanism.

Critical Impact
An attacker holding a previously leaked password reset link can hijack a FOSSBilling client account because subsequent reset requests do not rotate or invalidate the existing token.

Affected Products

FOSSBilling 0.5.6 through 0.7.2
FOSSBilling reset_password guest API endpoint
FOSSBilling client_password_reset database records

Discovery Timeline

2026-07-06 - CVE-2026-53646 published to NVD
2026-07-07 - Last updated in NVD database

Technical Details for CVE-2026-53646

Vulnerability Analysis

The flaw resides in the password reset workflow exposed through the reset_password guest API endpoint. When a user initiates a password reset, FOSSBilling checks whether a ClientPasswordReset record already exists for that client. If one is present and has not expired, the application reuses the existing token and re-emails the same reset link instead of creating a fresh token. This behavior collapses multiple independent reset requests into a single reusable credential. Because the token lifetime is measured from the initial created_at timestamp, requesting a new reset does not extend, rotate, or invalidate the original link. Any actor who previously observed or intercepted the first reset URL retains valid access until the 15-minute window elapses.

Root Cause

The root cause is an insecure password recovery design [CWE-640]. The reset handler treats the presence of an existing unexpired record as a signal to short-circuit token generation, rather than treating each user-initiated reset as an event that must produce a new secret and invalidate prior ones. Tokens are neither rotated on re-request nor bound to a single delivery attempt.

Attack Vector

Exploitation requires that an attacker previously obtained a valid reset link, for example through email interception, log exposure, referrer leakage, or shoulder surfing. When the legitimate user later requests a new reset because the first email appeared suspicious or was missed, FOSSBilling re-sends the same token. The attacker uses the original link to set a new password and take over the account. User interaction from the victim is required to trigger the second request, and the attack must complete within the 15-minute window anchored to the first request.

See the FOSSBilling GitHub Security Advisory GHSA-vp66-w6rc-x32p for vendor technical details.

Detection Methods for CVE-2026-53646

Indicators of Compromise

Multiple POST /client/reset-password requests for the same client email from differing source IP addresses within a 15-minute window.
client_password_reset records where the created_at timestamp is significantly older than the most recent reset email delivery time.
Successful password change events immediately following a reset request originating from an IP that differs from the client's historical login IPs.

Detection Strategies

Correlate application logs for reset requests with mail server logs to identify cases where a reset email was resent but no new token was created.
Alert on password reset completions where the completing IP or User-Agent differs from the IP that most recently requested the reset.
Query the client_password_reset table for records reused across multiple email dispatches by comparing send counters against created_at values.

Monitoring Recommendations

Log every call to the reset_password guest API endpoint with source IP, User-Agent, and target client identifier.
Track account takeover indicators such as password changes followed by contact detail or payout modifications on FOSSBilling client accounts.
Forward FOSSBilling and reverse-proxy access logs to a centralized analytics platform for retention and correlation.

How to Mitigate CVE-2026-53646

Immediate Actions Required

Upgrade FOSSBilling to version 0.8.0 or later, which rotates tokens on each reset request.
Purge existing rows from the client_password_reset table to invalidate any tokens issued under the vulnerable code path.
Notify clients who reported suspicious reset emails and require them to request a new password reset after the upgrade.

Patch Information

FOSSBilling 0.8.0 remediates the issue by ensuring that new reset requests either regenerate the token or invalidate any prior ClientPasswordReset record for the client. Administrators should review the GitHub Security Advisory GHSA-vp66-w6rc-x32p for full upgrade guidance.

Workarounds

Configure a reverse proxy such as Nginx, Apache, or Cloudflare to apply per-IP rate limiting to the /client/reset-password endpoint, reducing the window in which reset abuse can occur.
Manually clear expired client_password_reset records from the database whenever a client reports a suspected compromise or unexpected reset email.
Restrict access to mail infrastructure and audit any systems that could log or intercept password reset URLs.

bash

# Nginx per-IP rate limiting for the password reset endpoint
limit_req_zone $binary_remote_addr zone=fossbilling_reset:10m rate=5r/m;

server {
    location /client/reset-password {
        limit_req zone=fossbilling_reset burst=3 nodelay;
        proxy_pass http://fossbilling_backend;
    }
}