CVE-2026-71862: Checkmate Information Disclosure Vulnerability

CVE-2026-71862 Overview

Checkmate is an open-source, self-hosted server monitoring tool that tracks hardware, uptime, response times, and incidents. Versions 3.3.0 through 3.9.1 expose monitor credentials through an unauthenticated status page API endpoint. When the global showURL setting is enabled, the GET /api/v1/status-page/:url endpoint returns complete monitor objects, including the secret field used for HTTP Authorization credentials. Although the frontend component BaseStatusPage.tsx does not render this field, attackers can extract it directly from the JSON response. The issue is tracked as CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and is fixed in version 3.9.2.

Critical Impact
Unauthenticated remote attackers can harvest HTTP Authorization credentials from public status pages and reuse them against monitored backend services.

Affected Products

Checkmate versions 3.3.0 through 3.9.1 (bluewave-labs/Checkmate)
Deployments with the global showURL setting enabled
Fixed in Checkmate version 3.9.2

Discovery Timeline

2026-08-21 - CVE-2026-71862 published to NVD
2026-08-21 - Last updated in NVD database
v3.9.2 - Patch released via GitHub Release v3.9.2

Technical Details for CVE-2026-71862

Vulnerability Analysis

The vulnerability resides in server/src/controllers/statusPageController.ts, which handles the public status page endpoint. When showURL is globally enabled, the controller returns full monitor objects rather than a curated projection. The response payload includes the secret property that HttpProvider.ts populates as an HTTP Authorization header value for authenticated health checks.

The frontend component BaseStatusPage.tsx omits the secret field from rendered output, creating a false sense of confidentiality. Attackers bypass the UI entirely by requesting the JSON endpoint directly. Any visitor to a public status page URL can enumerate monitors and extract associated credentials without authentication.

Root Cause

The controller relied on a blacklist model for filtering sensitive monitor properties before serialization. Adding new sensitive fields such as secret without updating the exclusion list caused those values to leak. The fix inverts the model to a strict whitelist of monitor properties safe for public exposure.

Attack Vector

Exploitation requires only network reachability to a Checkmate deployment where showURL is enabled and at least one public status page exists. An attacker issues an HTTP GET request to /api/v1/status-page/:url and parses the JSON response. Extracted secret values can then be replayed against the monitored upstream services as HTTP Authorization credentials.

typescript

// Security patch: server/src/api/controllers/statusPageController.ts
 import { AppError } from "@/utils/AppError.js";
 import { requireTeamId, requireUserId } from "@/api/controllers/controllerUtils.js";
 import { IStatusPageService } from "@/domain/status-pages/status-page.service.js";
-import { IMonitorsRepository } from "@/domain/monitors/monitor.repository.interface.js";
-import { ISettingsService } from "@/domain/app-settings/app-settings.service.js";
-import { NormalizeData } from "@/utils/dataUtils.js";
 import { resolveStatusPageDomainFromRequest } from "@/utils/statusPageDomain.js";
-import type { StatusPage } from "@/domain/status-pages/status-page.type.js";

 const SERVICE_NAME = "statusPageController";

Source: GitHub Commit cc1814f

The controller wiring was also simplified in server/src/config/controllers.ts, removing direct access to the monitors repository and settings service from the status page path:

typescript

-		statusPageController: new StatusPageController(apiServices.statusPageService, apiServices.monitorsRepository, apiServices.settingsService),
+		statusPageController: new StatusPageController(apiServices.statusPageService),

Source: GitHub Commit cc1814f

Detection Methods for CVE-2026-71862

Indicators of Compromise

Unauthenticated GET requests to /api/v1/status-page/:url from non-browser user agents or automated scanners
Response payloads from the status page endpoint containing a populated secret field
Reuse of monitor Authorization header values in requests to internal upstream services from unexpected source IPs

Detection Strategies

Inspect reverse proxy or web server logs for high-frequency requests to /api/v1/status-page/ paths, particularly those consuming JSON directly rather than the HTML frontend
Audit outbound authentication activity from services monitored by Checkmate for credential reuse from unauthorized sources
Compare installed Checkmate versions against 3.9.2 across all self-hosted deployments

Monitoring Recommendations

Enable request logging on the Checkmate API tier and forward logs to a centralized analytics platform for retention and query
Rotate any HTTP Authorization secrets previously configured in Checkmate monitors and alert on continued use of the old values
Alert on any status page JSON response body containing the string "secret" at the egress layer

How to Mitigate CVE-2026-71862

Immediate Actions Required

Upgrade Checkmate to version 3.9.2 or later using the official release
Rotate all HTTP Authorization credentials configured as monitor secret values, treating them as exposed
Audit access logs on monitored services for unauthorized authentication attempts using the rotated credentials

Patch Information

The fix is delivered in Checkmate 3.9.2 via Pull Request #3758 and commit cc1814f. The patch replaces the blacklist-based property filter with a strict whitelist in the status page controller. See the GitHub Security Advisory GHSA-3m74-8cg9-rp8j for the full disclosure.

Workarounds

Disable the global showURL setting until the upgrade to 3.9.2 is deployed
Remove or unpublish public status pages that reference monitors with configured secret credentials
Restrict network access to /api/v1/status-page/:url via a reverse proxy allowlist during patch rollout

bash

# Example nginx block to temporarily deny the vulnerable endpoint
location ~ ^/api/v1/status-page/ {
    return 403;
}