CVE-2026-77021: Checkmk Agent Receiver Memory Exhaustion via Zlib Data Amplification

Q: What is the CVSS score for CVE-2026-77021?

CVE-2026-77021 has a CVSS 4.0 base score of 5.3, classified as medium severity. The attack vector is network-based with low attack complexity and low privileges required, and the impact is limited to low availability impact with no confidentiality or integrity impact.

Q: What is required to exploit CVE-2026-77021?

An attacker must control a host that has been registered with the Checkmk server for push-mode monitoring. The attacker sends a small zlib-compressed payload that decompresses to an arbitrary size, exhausting the memory of the agent receiver and causing denial of service.

Summary

CVE-2026-77021 is a medium-severity vulnerability in Checkmk’s agent receiver component caused by improper handling of highly compressed data, classified under CWE-409. An attacker who controls a host registered for push mode can send a deceptively small zlib-compressed payload that, upon decompression by the agent receiver, expands to an arbitrary size and exhausts available memory. The vulnerability affects Checkmk versions <2.5.0p14, <2.4.0p37, <2.3.0p51, and the end-of-life 2.2.0 release. It carries a CVSS 4.0 base score of 5.3, reflecting network-based exploitability with low attack complexity and low privileges required, but limited impact confined to availability.

Technical Analysis

The vulnerability resides in the agent receiver component of Checkmk, which is responsible for accepting monitoring data from hosts configured in push mode. In a typical push-mode deployment, a monitored host actively sends its agent data to the Checkmk server rather than waiting for the server to poll it. This data transmission uses zlib compression to reduce network bandwidth consumption during transfer.

The core problem is that the agent receiver does not impose adequate limits on the decompressed size of incoming zlib payloads. Zlib compression, like many general-purpose compression algorithms, can achieve extremely high compression ratios when the decompressed data contains repetitive or predictable patterns. A payload of just a few kilobytes on the wire can theoretically decompress to gigabytes in memory. This phenomenon is commonly referred to as a data amplification or decompression bomb attack.

Under normal operation, a monitored host sends a reasonably sized agent data payload—typically tens to hundreds of kilobytes of monitoring metrics, system information, and service checks. The zlib-compressed version of this data is even smaller in transit. The agent receiver accepts this compressed data, decompresses it in memory, and processes the resulting agent data for monitoring purposes. Because the receiver trusts the compressed payload to represent a legitimate agent data submission, it allocates memory for the full decompressed content without enforcing a maximum decompressed size boundary.

An attacker who controls a host that has been registered for push mode can exploit this trust relationship. By crafting a zlib-compressed payload that is small in its compressed form but expands to an enormous size upon decompression, the attacker forces the agent receiver to allocate memory far exceeding what would ever be needed for legitimate monitoring data. The receiver has no mechanism to detect or abort decompression when the output size becomes unreasonable, so it continues allocating memory until the process is killed by the operating system’s out-of-memory (OOM) killer or until the system becomes unresponsive.

The CVSS 4.0 vector string for this vulnerability is CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N. Breaking this down: the attack vector is network-based (AV:N), meaning the attacker can exploit the vulnerability over the network. The attack complexity is low (AC:L), as crafting a zlib decompression bomb is straightforward and requires no special conditions. No attacker interaction is needed (AT:N). The privileges required are low (PR:L) because the attacker must control a host that has been registered for push mode, which is a legitimate but restricted capability. There is no user interaction required (UI:N). The vulnerability has no impact on confidentiality or integrity (VC:N/VI:N) but has a low impact on availability (VA:L) of the vulnerable system. There is no impact on subsequent systems in terms of confidentiality, integrity, or availability.

The classification under CWE-409 (Improper Handling of Highly Compressed Data) is directly applicable here. CWE-409 describes scenarios where an application does not properly handle data that is highly compressed, allowing an attacker to amplify the amount of data processed and potentially causing resource exhaustion. This is precisely the mechanism exploited in CVE-2026-77021.

Affected Software and Versions

The vulnerability affects the following Checkmk versions:

Checkmk <2.5.0p14 — versions in the 2.5.0 release line prior to patch level p14
Checkmk <2.4.0p37 — versions in the 2.4.0 release line prior to patch level p37
Checkmk <2.3.0p51 — versions in the 2.3.0 release line prior to patch level p51
Checkmk 2.2.0 (EOL) — the entire 2.2.0 release line, which has reached end-of-life status and will not receive a security patch

Users running any of these versions should upgrade immediately to the corresponding fixed version: 2.5.0p14 or later, 2.4.0p37 or later, or 2.3.0p51 or later. Users on the 2.2.0 release line must migrate to a supported release line, as no patch will be issued for the end-of-life version.

Impact

The primary impact of CVE-2026-77021 is denial of service through memory exhaustion. When an attacker successfully exploits this vulnerability, the agent receiver process consumes all available memory on the Checkmk server as it attempts to decompress the malicious payload. The consequences include:

Agent receiver crash: The agent receiver process is terminated by the operating system’s OOM killer when memory is exhausted, disrupting the ingestion of monitoring data from all push-mode hosts.
System-wide instability: If the agent receiver consumes a significant portion of system memory, other processes on the same server may also be affected, potentially impacting the Checkmk web interface, the monitoring core, and other services.
Monitoring blind spots: While the agent receiver is unavailable, monitoring data from push-mode hosts cannot be collected, creating gaps in monitoring coverage that may delay detection of other critical issues.
Recurring attacks: If the agent receiver automatically restarts after being killed, an attacker can repeatedly send malicious payloads to maintain a persistent denial-of-service condition.

The CVSS score of 5.3 places this vulnerability in the medium severity range. The impact is limited to availability (VA:L) with no effect on confidentiality or integrity. However, the ease of exploitation—requiring only control of a registered push-mode host and the ability to send a crafted zlib payload—makes it a practical concern for environments where push-mode monitoring is used and host registration is delegated to parties that may not be fully trusted.

Exploitation Scenario

To exploit CVE-2026-77021, an attacker must meet the following prerequisites:

Control of a registered push-mode host: The attacker must have access to a host that has been registered with the Checkmk server for push-mode monitoring. This means the host’s registration credentials or agent configuration must be under the attacker’s control. This could occur if the attacker has compromised a legitimate monitored host, or if the attacker is an insider with legitimate access to register hosts.
Network access to the agent receiver: The attacker’s controlled host must be able to reach the Checkmk agent receiver service over the network. This is typically the same network path used for legitimate push-mode data submission.
Knowledge of the payload format: The attacker must be able to construct a zlib-compressed payload that the agent receiver will accept and attempt to decompress. The payload must be valid zlib data that decompresses to an extremely large output.

The attack proceeds as follows:

The attacker crafts a zlib-compressed payload designed to decompress to an arbitrarily large size. This can be achieved by compressing a file filled with repetitive data (such as a long sequence of null bytes or a repeated character pattern), which zlib can compress to a very small size while the original data is extremely large.
The attacker sends this compressed payload to the Checkmk agent receiver from the controlled push-mode host, using the same communication channel and protocol as a legitimate monitoring data submission.
The agent receiver receives the small compressed payload and begins decompressing it. Because no decompressed size limit is enforced, the receiver allocates memory for the full decompressed output.
As decompression proceeds, memory consumption rises dramatically. The compressed payload may be only a few kilobytes, but the decompressed output can be gigabytes in size.
The system runs out of memory, and the agent receiver process is killed by the OOM killer or becomes unresponsive, achieving denial of service.

An important aspect of this attack is its asymmetry: the attacker expends minimal bandwidth and computational effort to send a small compressed payload, while the server must allocate and fill a potentially enormous amount of memory. This makes the attack efficient and difficult to detect through network traffic analysis alone, as the incoming payload appears small and innocuous.

Detection and Mitigation

Detection

Detecting exploitation of CVE-2026-77021 involves monitoring for signs of memory exhaustion on the Checkmk server and identifying anomalous payloads from push-mode hosts:

Monitor memory usage: Set up alerts for sudden, unexplained spikes in memory consumption on the Checkmk server, particularly by the agent receiver process. Rapid memory growth that coincides with incoming push-mode data submissions is a strong indicator of a decompression bomb attack.
Monitor agent receiver process health: Track restarts of the agent receiver process. Frequent restarts caused by OOM kills may indicate repeated exploitation attempts.
Inspect incoming payload sizes: If feasible, log the compressed and decompressed sizes of incoming push-mode payloads. A payload with an extremely high compression ratio (e.g., a few kilobytes compressing to hundreds of megabytes) is suspicious and should be investigated.
Review registered push-mode hosts: Audit the list of hosts registered for push mode to ensure all registrations are legitimate and controlled by trusted parties.

Mitigation

The primary mitigation is to upgrade to a fixed version of Checkmk:

For the 2.5.0 release line, upgrade to 2.5.0p14 or later.
For the 2.4.0 release line, upgrade to 2.4.0p37 or later.
For the 2.3.0 release line, upgrade to 2.3.0p51 or later.
For the 2.2.0 release line, migrate to a supported release line (2.3.0, 2.4.0, or 2.5.0) and then apply the corresponding patch. No fix will be provided for the end-of-life 2.2.0 release.

Additional mitigation measures include:

Restrict push-mode host registration: Limit the ability to register hosts for push mode to trusted administrators and systems. This reduces the risk of an attacker gaining the necessary access to exploit the vulnerability.
Network-level controls: Restrict network access to the agent receiver service to only known, trusted host IP addresses. This can prevent unauthorized hosts from submitting payloads even if they have registration credentials.
Resource limits: Configure system-level resource limits (such as ulimit settings or systemd resource controls) for the agent receiver process to limit the amount of memory it can consume. While this does not fix the underlying vulnerability, it can prevent a single malicious payload from exhausting all system memory.
Monitoring and alerting: Implement automated monitoring for memory exhaustion events and configure alerts to notify administrators immediately when the agent receiver is killed or when memory usage spikes abnormally.

Bug Bounty Angle

CVE-2026-77021 represents a class of vulnerability that is often overlooked in security assessments: resource exhaustion through improper handling of compressed data. For bug bounty hunters and security researchers, this vulnerability highlights several important areas of focus:

Decompression bomb testing: Any application that accepts compressed data from external sources should be tested for decompression bomb vulnerabilities. This includes not only zlib but also gzip, bzip2, LZ4, and other compression formats. The key question is whether the application enforces a maximum decompressed size limit before or during decompression.
Trust boundary analysis: This vulnerability exploits a trust boundary where the agent receiver trusts data from registered push-mode hosts. Researchers should examine whether all data from registered hosts is properly validated, or whether the registration status is used as a blanket trust mechanism that bypasses input validation.
Compression ratio monitoring: Applications that process compressed data should monitor the compression ratio and reject payloads with suspiciously high ratios. A legitimate monitoring data payload is unlikely to have a compression ratio of thousands-to-one, so such a ratio should trigger rejection.
Resource limit enforcement: Researchers should evaluate whether applications enforce resource limits (memory, CPU, time) when processing untrusted or semi-trusted input. The absence of such limits is a common root cause of denial-of-service vulnerabilities.

The fact that this vulnerability requires only low privileges (control of a registered push-mode host) and can be exploited with low attack complexity makes it a valuable finding for bug bounty programs. The impact, while limited to availability, can be significant in monitoring environments where continuous visibility is critical.

Frequently Asked Questions

What is the CVSS score for CVE-2026-77021?