Checkmk CVE-2025-32916

Exploitation requires that sensitive form data actually be submitted through affected Checkmk GUI workflows that use the GET method, so that the values land in URL query strings - and then it requires separate access to a location where those URLs are retained (the victim's browser history, the Checkmk/web server access logs, or any intermediary proxy or SIEM that logs full URLs). Per the vendor CVSS 4.0 metrics, the attacker needs high privileges (PR:H) and there is a passive user-interaction requirement (UI:P) plus an additional attack requirement (AT:P); the vector is local (AV:L), not remote-unauthenticated. The flaw discloses information only (VC:L, VI:N, VA:N); it does not by itself grant code execution or data modification. Limiting factors: it is not reachable over the network without access to the log/history store, affects a bounded set of forms, and impact is confined to whatever sensitive fields were passed via GET.

This is a genuinely low-priority issue, and all available signals agree. The vendor-supplied CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:H/UI:P/VC:L/VI:N/VA:N) produces a base score of 1.0, driven by requirements for local/adjacent context, high privileges (PR:H), passive user interaction (UI:P), an additional attack requirement (AT:P), and only low confidentiality impact with no integrity or availability impact. EPSS reinforces this: 0.19% probability at the 8th percentile indicates near-zero likelihood of exploitation activity. There is no CISA KEV listing and no public proof-of-concept, so there is no evidence of exploitation. The weakness (CWE-598, sensitive information in GET query strings) is an information-exposure/hygiene flaw rather than a directly exploitable code defect - the 'attacker' is really anyone with access to browser history, web server logs, or proxy/intermediary logs where the URL was recorded. No signals conflict here; the only nuance is that CVSS 3.1 metrics were not supplied, so the independent 3.1 vector below is inferred from the description and the vendor's 4.0 metrics.

A Checkmk user submits a form whose sensitive data is placed into URL query parameters; those URLs are then retained in browser history, web server access logs, or intermediary proxy logs. A party with later access to any of those log stores - a co-user of a shared workstation, a log administrator, or an operator of a logging proxy - reads the sensitive values from the recorded URLs. No public exploit code exists and no active exploitation has been reported.