CVE-2025-39664 in Checkmk
Summary
by MITRE • 10/09/2025
Insufficient escaping in the report scheduler within Checkmk <2.4.0p13, <2.3.0p38, <2.2.0p46 and 2.1.0 (EOL) allows authenticated attackers to define the storage location of report file pairs beyond their intended root directory.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 12/05/2025
This vulnerability exists in Checkmk monitoring software versions prior to specific patch releases, specifically affecting versions before 2.4.0p13, 2.3.0p38, 2.2.0p46, and the end-of-life 2.1.0 release. The flaw resides within the report scheduler component where insufficient input validation and escaping mechanisms allow authenticated attackers to manipulate file storage paths. This vulnerability represents a path traversal issue that falls under CWE-22 Path Traversal and CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component. The security implications are significant as it enables attackers to write report files outside of designated storage directories, potentially leading to arbitrary file creation or modification in the system's file hierarchy.
The technical implementation of this vulnerability allows an authenticated attacker to craft malicious report scheduler configurations that bypass directory restrictions. When the report scheduler processes user-defined storage locations for report file pairs, the application fails to properly sanitize or validate the input paths, enabling attackers to use directory traversal sequences such as ../ or ..\ to navigate outside the intended root directory. This weakness specifically affects the file path resolution mechanism within the report generation pipeline, where the application should enforce strict boundaries on where generated files can be stored. The vulnerability is particularly dangerous because it operates within the context of an authenticated user, meaning that an attacker must first establish credentials but does not require elevated privileges beyond normal user access.
The operational impact of this vulnerability extends beyond simple file system manipulation. Attackers could potentially write malicious files to critical system locations, overwrite existing important files, or create backdoor entries within the monitoring infrastructure. The compromised report scheduler functionality could enable attackers to establish persistent access points through report generation processes that run automatically. This vulnerability also creates opportunities for privilege escalation if the report scheduler operates with elevated permissions or if the attacker can manipulate report generation to include malicious payloads. The attack surface is particularly concerning in environments where Checkmk is used for critical infrastructure monitoring, as it could allow adversaries to compromise the integrity of monitoring data or disrupt system operations through file system manipulation.
Organizations should immediately apply the security patches available for Checkmk versions 2.4.0p13, 2.3.0p38, 2.2.0p46, and ensure that the end-of-life 2.1.0 version is upgraded to a supported release. The recommended mitigation strategy involves implementing strict input validation and sanitization for all user-provided file paths within the report scheduler component. Network segmentation and access controls should be reinforced to limit the scope of potential exploitation, particularly for users with report scheduling privileges. Additionally, monitoring for unusual file creation patterns or access to unexpected file locations should be implemented to detect potential exploitation attempts. This vulnerability aligns with ATT&CK technique T1059 Command and Scripting Interpreter and T1566 Phishing as it could be exploited through authenticated access to create malicious report files that might be used for further attacks or data exfiltration. Regular security audits of file system permissions and monitoring of report generation activities should be part of the defensive strategy to prevent unauthorized file system modifications.