EUVD-2026-70973
GHSA-p53j-vwhv-xp3w
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessControl relay or push agent with shared UUID
-
DeliveryExtract mTLS certificate and private key
-
ExploitPresent peer component's cert to agent receiver endpoint
-
ExecutionBypass root-CA ownership check
-
PersistAuthenticate as peer agent role
-
ImpactRead monitoring data or inject falsified metrics
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
|
| Exploitation Conditions | Exploitation requires two specific preconditions: first, a relay agent and a push agent must share the same UUID within the Checkmk deployment, a non-default condition typically caused by template cloning or misconfiguration; second, the attacker must have control of one of these agent components (or access to its private mTLS key), satisfying the PR:L requirement. The vulnerable pathway is limited to agent receiver endpoint authentication and does not affect other Checkmk communication channels or the central site UI. Environments using only one agent type (relay-only or push-only), or where UUID uniqueness is enforced, are not affected. The attack is bounded to the network segment reachable by the controlled agent. |
| Impact | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N) scores 5.3 (Medium), reflecting limited per-hop impact and a requirement for low-level privileges. The critical real-world constraint is the prerequisite that a relay and push agent share the same UUID, which is non-default and would arise from misconfiguration, template-based deployments where cloned agents inherit the same identifier, or deliberate attacker staging. This CVE is not listed in CISA KEV and no POC or EPSS data are present in the available input, consistent with no observed active exploitation. The VI:L integrity impact is operationally significant for a monitoring platform: an attacker impersonating an agent role could inject falsified health data or suppress alerts, undermining the security visibility Checkmk is deployed to provide. Organizations using Checkmk in security-monitoring or compliance roles should treat the integrity risk as higher than the raw score implies. |
| Exploit ScenarioDerived | An attacker who has compromised a push agent registered with UUID X - for example, by obtaining its private key from a cloned or misconfigured host - presents that agent's mTLS certificate to an agent receiver endpoint that also accepts a relay agent registered with the same UUID X. The receiver, lacking root-CA ownership validation, accepts the certificate and grants the attacker relay-role access, allowing injection of falsified monitoring data or interception of agent communication. No public exploit code has been identified. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 04, 2026
mTLS certificate reuse in Checkmk before 2.5.0p10 enables a relay or push agent to authenticate against agent receiver endpoints using a peer component's certificate, provided both share the same UUID. The agent receiver endpoints fail to verify that a presented client certificate was issued by their own root CA, breaking the intended role-based trust boundary between relay and push agent components. No public exploit has been identified, and exploitation requires an attacker to already control one of the affected agent components (PR:L), limiting realistic risk despite the network-reachable vector.
RemediationAI
Upgrade Checkmk to version 2.5.0p10 or later, which corrects the agent receiver endpoint's certificate validation logic to enforce root-CA ownership verification; see the vendor advisory at https://checkmk.com/werk/19735. Where immediate upgrade is not feasible, administrators should audit all agent UUID assignments to ensure no relay agent and push agent share the same UUID - eliminating the precondition for exploitation. This audit requires reviewing agent registration configurations across the Checkmk site and is a manual process; it does not close the underlying validation gap and must be followed by patching. Restricting network access to agent receiver endpoints to known, enumerated agent IP addresses provides additional depth but does not address the certificate validation flaw directly.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Checkmk is an enterprise IT monitoring platform that uses mutual TLS (mTLS) to authenticate communication between its distributed components: 'relay' agents (which aggregate data from monitored hosts), 'push' agents (which stream metrics to the central server), and 'agent receiver' endpoints that accept this data. CWE-295 (Improper Certificate Validation) applies here because the receiver endpoint accepts any certificate bearing a matching UUID without verifying that the certificate was signed by its own root CA. When a relay and a push agent are registered with the same UUID, each component's certificate becomes valid proof of identity for the other at the receiver, collapsing the cryptographic separation between agent roles. The CPE cpe:2.3:a:checkmk_gmbh:checkmk:*:*:*:*:*:*:*:* covers all Checkmk versions up to the fix.
Know when Checkmk gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
UUID-sharing precondition makes exploitation non-trivial (AC:H); controlling one agent component is required (PR:L); no availability impact.
Primary rating from Vendor (Checkmk).
CVSS VectorVendor: Checkmk
Lifecycle Timeline
1DescriptionCVE.org
Improper certificate validation in Checkmk <2.5.0p10 allows a relay and a push agent that share the same UUID to reuse each other's mTLS certificate to authenticate against agent receiver endpoints in either direction, because the endpoints do not verify that the certificate was issued by their own root certificate.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Check_MK before 1.2.8p26 mishandles certain errors within the failed-login save feature because of a race condition, whi
The web management console of CheckMK Raw Edition (versions 1.5.0 to 1.6.0) allows a misconfiguration of the web-app Dok
The web management console of CheckMK Enterprise Edition (versions 1.5.0 to 2.0.0p9) does not properly sanitise the uplo
Local privilege escalation in the Checkmk Windows Agent's Windows License plugin allows an authenticated low-privileged
Stored/transmitted cross-site scripting in Checkmk's distributed monitoring lets an attacker who already controls a remo
Authenticated path traversal in Checkmk's report scheduler lets a user with valid application credentials write report f
Improper restriction of excessive authentication attempts on some authentication methods in Checkmk before 2.3.0b5 (beta
The CheckMK management web console (versions 1.5.0 to 2.0.0) does not sanitise user input in various parameters of the W
Local privilege escalation in Checkmk allows site users with high privileges to escalate to root by manipulating site co
Bypass of two factor authentication in RestAPI in Checkmk < 2.3.0p16 and < 2.2.0p34 allows authenticated users to bypass
Improper neutralization of active check command arguments in Checkmk < 2.1.0p32, < 2.0.0p38, < 2.2.0p4 leads to arbitrar
Improper neutralization of livestatus command delimiters in the RestAPI in Checkmk < 2.0.0p36, < 2.1.0p28, and < 2.2.0b8
Exploit-DB