Checkmk EUVD-2026-112694

Exploitation requires two concurrent conditions: (1) the attacker must possess one of the eight compromised eMudhra (emSign) intermediate CA private keys, which are publicly known, and (2) the attacker must hold an on-path/man-in-the-middle position between a vulnerable Checkmk instance and the TLS endpoint it connects to (this is the AT:P attack requirement). It applies only to Checkmk builds before 2.5.0p18, 2.4.0p39, and 2.3.0p52, plus the EOL 2.2.0 line, that rely on the affected certifi/webpki-roots CA bundles. The primary limiting factor is the on-path requirement; no authentication (PR:N) and no user interaction (UI:N) are needed once that position is achieved. The complete fix per the vendor is to update to the fixed Checkmk versions (which ship corrected bundles); for vendored certifi, upgrade to 2026.10.19 or later and rebuild any container images that bundle certifi.

This is an improper-certificate-validation flaw (CWE-295): Checkmk versions before 2.5.0p18, 2.4.0p39, 2.3.0p52 (and EOL 2.2.0) ship the certifi and webpki-roots CA bundles, which trusted the 'emSign ECC Root CA - G3' root that in turn trusts eight eMudhra (emSign) intermediate CAs whose private keys are public and have been revoked. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 7.1 and signals a network, unauthenticated issue, but the AT:P flag correctly reflects that a specific attack requirement - an on-path/man-in-the-middle position - must hold, so this is not a trivially remote 'spray' bug. There is no CISA KEV listing and no EPSS score in the supplied data, and no working exploit code is referenced; the realistic risk driver is that the compromised intermediate keys are already public, lowering the attacker skill barrier to the point where only network positioning gates abuse. The vuln.today decision label is 'this_week' rather than act_now/emergency, consistent with a serious-but-conditional TLS trust issue: treat it as a prompt patch item, not an active-exploitation fire drill. Note the input provides only a CVSS 4.0 vector (no 3.1 vector) and no EPSS value - exploitation likelihood is inferred from the public-key fact, not from a probability score.

An attacker obtains one of the eight publicly exposed eMudhra intermediate CA private keys and uses it to mint a valid-looking TLS certificate for a hostname a Checkmk instance communicates with. Positioned on-path between Checkmk and that endpoint, the attacker presents the forged certificate; because the bundled certifi/webpki-roots store still trusts the emSign root, the client accepts it and the attacker can intercept or modify the TLS traffic. No working public exploit code is referenced, but the required intermediate keys are themselves public.