Checkmk CVE-2025-64997

Exploitation requires an authenticated Checkmk user account with low privileges (PR:L) who can reach the Checkmk REST API over the network; it is not anonymous/unauthenticated. The specific prerequisite is access to the REST API agent-information endpoints whose permission validation is insufficient in Checkmk versions before 2.4.0p17 (2.4.x branch) and before 2.3.0p42 (2.3.x branch); the 2.2.0 line also appears in affected CPEs. Limiting factors: an attacker must already possess valid credentials for a low-privileged role, the impact is confined to information disclosure (no integrity or availability effect), and patched builds (2.4.0p17 / 2.3.0p42) close the issue. No special non-default feature toggle is described - the flaw is in the API's authorization logic itself.

This is a moderate, authenticated information-disclosure flaw that signals operate consistently toward LOW-to-MODERATE real-world priority rather than an emergency. The CVSS 4.0 base score is 6.3 (Medium) with AV:N/AC:L/PR:L/UI:N, meaning network-reachable and low-complexity but requiring an existing low-privileged authenticated account - not anonymous. EPSS is 0.24% (14th percentile), which is low and consistent with the absence of both CISA KEV listing and any public POC; there is no evidence of active exploitation. The impact signals are narrow: VC:L (limited confidentiality) with VI:N/VA:N (no integrity or availability impact), so this is purely a read/disclosure issue. One notable tension: the vendor's CVSS 4.0 vector sets SC:H (High subsequent-system confidentiality impact), which pushes the score up and implies that disclosed agent information meaningfully exposes monitored downstream hosts - yet VC is only L; this asymmetry is the main driver of the 6.3 and should be weighed by defenders, as the practical severity depends on how sensitive the exposed agent data is in a given environment. No SSVC decision data was provided. Overall: a genuine least-privilege/broken-access-control bug worth patching in the normal cycle, but not a drop-everything priority given authentication is required and no exploitation activity exists.

A user with a low-privileged Checkmk account (e.g., a restricted operator or read-only monitoring user) sends authenticated requests to the Checkmk REST API endpoints that return agent information, which the permission model should have blocked for their role. Because permission validation is insufficient, the API returns agent/host monitoring data the user was not authorized to see, disclosing configuration or infrastructure details about monitored systems. No public exploit code or active exploitation has been identified at time of analysis.