CVE-2026-71862 in Checkmate
Summary
by MITRE • 08/21/2026
Checkmate is an open-source, self-hosted tool designed to track and monitor server hardware, uptime, response times, and incidents in real-time with beautiful visualizations. From 3.3.0 until 3.9.2, enabling the global showURL setting causes the unauthenticated GET /api/v1/status-page/:url endpoint to return complete monitor objects from server/src/controllers/statusPageController.ts. The response includes the secret field used by HttpProvider.ts as an HTTP Authorization credential, even though BaseStatusPage.tsx does not display that value, allowing visitors to extract credentials from the JSON response and use them against monitored services. This issue is fixed in version 3.9.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The Checkmate application serves as a comprehensive open-source solution for monitoring server hardware health, uptime metrics, response times, and incident tracking through real-time visualizations. While the tool provides robust functionality for system administrators to maintain infrastructure stability, it contains a critical information disclosure vulnerability within specific versions ranging from 3.3.0 up to but not including version 3.9.2. This flaw is triggered by a misconfiguration involving the global showURL setting and affects the unauthenticated GET endpoint located at /api/v1/status-page/:url. The core technical failure lies in the server-side controller logic found within src/controllers/statusPageController.ts, which fails to properly sanitize or filter sensitive data fields before serializing monitor objects for transmission over HTTP.
When an attacker accesses this specific status page endpoint without providing any authentication credentials, the API response includes complete monitor object structures rather than just public-facing metrics. Crucially, these JSON responses contain a secret field that is intended solely for internal use by HttpProvider.ts as an HTTP Authorization credential to authenticate requests against monitored downstream services. Although the frontend component BaseStatusPage.tsx correctly omits this value from its visual display to prevent casual observation by users viewing the dashboard, the backend logic does not apply equivalent filtering during data serialization. This discrepancy between presentation-layer security and API-level data handling creates a significant exposure vector where sensitive authentication tokens are inadvertently leaked in plain text within the JSON payload returned to any visitor of the status page.
The operational impact of this vulnerability is severe because it allows unauthenticated actors to extract valid credentials for monitored services directly from the network traffic or response body. Once obtained, these secrets can be used by attackers to authenticate against the underlying monitored systems, potentially leading to unauthorized access, data exfiltration, service disruption, or further lateral movement within the organization's infrastructure. This represents a classic case of sensitive information exposure where internal implementation details are mistakenly exposed through public-facing interfaces due to incomplete filtering mechanisms in the API response generation process.
From a classification perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information and more specifically CWE-798: Use of Hard-coded Credentials if those secrets were static, but primarily falls under CWE-200 or general information leakage categories where sensitive data is accessible to unauthorized actors. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1530 Data from Local System which involves accessing local files and resources not intended for public consumption, as well as aspects of T1078 Valid Accounts if the extracted credentials are actively used to gain access. The root cause is a failure in data sanitization prior to serialization, highlighting the importance of ensuring that API responses strictly adhere to the principle of least privilege regarding data exposure regardless of frontend display logic.
To mitigate this issue and prevent similar vulnerabilities in future development cycles, it is essential to implement strict server-side filtering of sensitive fields such as secrets or tokens before they are included in any JSON response destined for unauthenticated endpoints. Developers should adopt a whitelist approach where only explicitly defined public metrics are serialized, rather than relying on blacklist approaches that may miss new secret fields added over time. Additionally, implementing comprehensive unit tests that verify the absence of sensitive data in API responses can help catch these regressions early in the development lifecycle. Organizations currently running versions 3.3.0 through 3.9.2 should immediately upgrade to version 3.9.2 or later where this flaw has been resolved by ensuring the secret field is excluded from the status page response payload regardless of global settings.