Checkmk CVE-2026-9549

The attacker must hold Checkmk administrator privileges sufficient to create or modify active or custom check configurations - confirmed by the CVSS PR:H metric. The victim must be a separate user, either another administrator or any account with host read permissions, who navigates to the service discovery page for the relevant host and triggers or views the affected check output - confirmed by the CVSS UI:P metric. The XSS payload fires only within the service discovery view, not across other Checkmk pages. Exploitation is bounded by the high privilege bar required for the attacker, the requirement for a distinct victim to interact with the page, and the narrow injection surface limited to active and custom check output fields. The effectiveness of session-theft impact further depends on whether Checkmk session cookies are marked HttpOnly, which may prevent direct JavaScript access to cookie values.

The CVSS 4.0 score of 4.8 (Medium) reflects a balanced picture: the network attack vector (AV:N) and low complexity (AC:L) are offset substantially by the high privilege requirement (PR:H) and the need for victim interaction (UI:P). In practice the attacker must already hold Checkmk administrator rights sufficient to configure active or custom checks - a significant pre-condition that sharply limits the realistic attacker population to insiders or accounts that have already been compromised. Impact is constrained to low integrity effects on the vulnerable and subsequent systems (VI:L, SI:L) with no confidentiality or availability impact confirmed by the CVSS vector (VC:N, VA:N, SC:N, SA:N). No EPSS data was provided in the intelligence feed; exploitation probability is therefore inferred from CVSS signals alone. The vulnerability is not listed in CISA KEV, and no public proof-of-concept has been identified at time of analysis. Real-world risk is most relevant in scenarios involving malicious or compromised administrators attempting to escalate impact against other privileged users within the same Checkmk instance, rather than as an external entry point.

A malicious or compromised Checkmk administrator configures an active or custom check whose output contains a JavaScript payload - for example, a script that exfiltrates session cookies or performs privileged actions through the Checkmk web interface. When another administrator or a user with host read permissions later opens the service discovery page for the affected host and runs or views the check, the stored script executes silently in their browser within the Checkmk application context, potentially enabling session hijacking or unauthorized configuration changes.