CVE-2026-72588: Checkmate User Enumeration Vulnerability

CVE-2026-72588 Overview

CVE-2026-72588 is a user enumeration vulnerability in bluewave-labs/Checkmate through version 2.1.0. The POST /api/v1/auth/recovery/request endpoint returns different HTTP status codes based on whether a submitted email address is registered. Registered addresses receive an HTTP 200 response, while unregistered addresses receive a different status code. This response discrepancy allows an unauthenticated remote attacker to identify valid user accounts. The issue is classified under [CWE-204: Observable Response Discrepancy]. While the vulnerability does not directly compromise account credentials, enumerated accounts enable targeted phishing, credential stuffing, and password spraying campaigns against confirmed users.

Critical Impact
Unauthenticated attackers can remotely enumerate valid user email addresses through the password recovery endpoint, enabling downstream account-targeted attacks.

Affected Products

bluewave-labs/Checkmate through version 2.1.0
Deployments exposing the /api/v1/auth/recovery/request endpoint to untrusted networks
Self-hosted Checkmate monitoring instances

Discovery Timeline

2026-08-10 - CVE-2026-72588 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-72588

Vulnerability Analysis

Checkmate is an open-source infrastructure monitoring platform maintained by bluewave-labs. The password recovery workflow accepts an email address via the POST /api/v1/auth/recovery/request endpoint. The server's response varies based on whether the email exists in the user database.

Registered email addresses trigger the recovery workflow and return HTTP 200. Unregistered email addresses return a different status code, exposing account existence through response side-channel information. An attacker can automate requests across an email list and classify each address as registered or not.

This behavior maps to [CWE-204: Observable Response Discrepancy]. The vulnerability affects confidentiality only, with no direct impact on integrity or availability. Enumerated accounts are then leveraged for targeted phishing and credential-based attacks against confirmed users of the Checkmate instance.

Root Cause

The root cause is inconsistent response handling in the password recovery request logic. Secure implementations return a uniform response (typically HTTP 200 with a generic message) regardless of whether the submitted email is registered. Checkmate through 2.1.0 diverges from this pattern by returning distinguishable status codes.

Attack Vector

The attack requires no authentication and no user interaction. An attacker sends HTTP POST requests to /api/v1/auth/recovery/request with candidate email addresses in the JSON body. By observing the response status code, the attacker builds a list of confirmed accounts. The endpoint is remotely reachable wherever the Checkmate API is exposed. No verified exploit code is publicly available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. See the Checkmate GitHub repository for source references.

Detection Methods for CVE-2026-72588

Indicators of Compromise

High volume of POST requests to /api/v1/auth/recovery/request from a single source IP or narrow IP range within a short window
Sequential recovery requests with varied email addresses matching common enumeration patterns (dictionary-based, breach-list-based)
Recovery request traffic without corresponding legitimate password reset completions

Detection Strategies

Rate-limit and log all requests to authentication endpoints, especially /api/v1/auth/recovery/request
Alert on abnormal ratios of recovery requests to successful password resets
Correlate source IPs performing recovery requests with subsequent login or credential stuffing attempts

Monitoring Recommendations

Ingest Checkmate application logs and reverse-proxy access logs into a centralized SIEM for query and alerting
Track per-IP request rates against authentication endpoints and baseline normal usage
Monitor for HTTP 200 versus non-200 response distributions on the recovery endpoint from external sources

How to Mitigate CVE-2026-72588

Immediate Actions Required

Upgrade Checkmate to a version later than 2.1.0 once a fixed release is published by bluewave-labs
Place the Checkmate API behind an authenticated reverse proxy or VPN where operationally feasible
Apply IP-based and account-based rate limiting to /api/v1/auth/recovery/request

Patch Information

At the time of publication, monitor the bluewave-labs/Checkmate GitHub repository for a patched release addressing CVE-2026-72588. The fix should normalize the recovery endpoint to return a uniform response regardless of email registration status.

Workarounds

Deploy a Web Application Firewall (WAF) rule that returns a uniform HTTP 200 response for all requests to /api/v1/auth/recovery/request regardless of the upstream response
Enforce aggressive rate limits (for example, 5 requests per IP per hour) on the recovery endpoint at the reverse proxy
Require CAPTCHA on the password recovery form to raise the cost of automated enumeration

bash

# Example nginx rate-limit configuration for the recovery endpoint
http {
    limit_req_zone $binary_remote_addr zone=recovery_zone:10m rate=5r/m;

    server {
        location /api/v1/auth/recovery/request {
            limit_req zone=recovery_zone burst=2 nodelay;
            proxy_pass http://checkmate_backend;
        }
    }
}