Vulnerability disclosure policy

At tribe29 we are committed to delivering software and hardware that offer the best quality to our users and customers. The security team at tribe29 contributes to this objective by striving to ensure the security of our products, both, during their development and after their release. To that end, we are continuously scanning and testing our software and hardware to identify potential vulnerabilities and to mitigate them as soon as possible.

In addition to our efforts, we rely on external sources to help us identify vulnerabilities in our products. Hence, we encourage everyone, including security researchers, customers, partners, Computer Emergency Response Teams (CERT) groups, and any other source, to report identified vulnerabilities.

Furthermore, we respect the will of reporting parties to maintain their anonymity and welcome anonymous submissions. In return, we strongly encourage coordinated disclosure of vulnerabilities and kindly ask the reporting parties to maintain the confidentiality of found vulnerabilities until they have been fixed. As mentioned in our Vulnerability Management Policy, we aspire to address reported vulnerabilities within a period of 90 days.


If you identified a vulnerability in one of our products (listed below), please send your findings in English or German via email to If you found more than one vulnerability, please send one email per finding. For each of the submitted finding(s) you should include the following information:

  • Description of the identified vulnerability, including the type of vulnerability, the vulnerable component(s), and an example of how an attacker can exploit this vulnerability. The more details you include in your report, the easier and swifter for our security team to triage and verify the existence of the vulnerability.
  • Proof-of-concept exploit that leverage the identified vulnerability. Video demonstrations in the form of screencasts are also accepted.
  • We would like to give recognition to the reporting parties. If you want your name/email/twitter handle/... to be associated with the finding(s), please let us know.

After submission, the tribe29 security team will contact you within a few business days. In their response the team will either acknowledge the vulnerability or ask for further details on how to reproduce the vulnerability. For more information about our internal process, please refer to our Vulnerability Management Policy.

tribe29's Promise

We appreciate your submissions and your willingness to help tribe29 develop and maintain high-quality, secure software. Following this responsible disclosure policy, we assure you to make our best effort to:

  • Respond to your submissions as quickly as we can, ideally within a few days.
  • Contact you with further questions about the submitted finding, if we could not reproduce it.
  • Recognize your effort in accordance with our current company policies and your willingness to be mentioned.
  • Not to pursue claims against reporting parties provided that:
    • The reporting parties do not cause deliberate harm to tribe29, its partners, or its customers.
    • The reporting parties do not violate the privacy or safety of tribe29, its partners, or its customers.
    • The reporting parties do not violate criminal law.


In Scope

The following codebases, web applications, and appliances are in scope of the responsible disclosure program:

  • The Checkmk codebase.
  • The Checkmk K8s cluster collector
  • The Checkmk Grafana datasource
  • The Checkmk website and its subdomains:
  • The Checkmk appliance.

At tribe29, we accept reports that span a wide array of vulnerabilities, provided that they are not in the out-of-scope list, and are accompanied by a PoC, so we can use to verify the submissions.

Out of Scope

The following attacks are not in the scope of this responsible disclosure program:

  • Self-XSS that cannot be exploited against other users.
  • (Distributed) Denial of Service (DDoS) attacks against the aforementioned domains, machines running Checkmk, or the Checkmk appliances.
  • Lack of HSTS enforcement for Checkmk web applications.
  • Missing Cookie flags without a PoC on how this can be exploited.
  • Missing security headers without a PoC on how this can be exploited.
  • HTTP Request smuggling without any proven business impact.
  • Blind SSRF without proven business impact (DNS pingback only is not sufficient).
  • HTTP Host headers manipulation without a proven business impact.
  • Disclosed and/or misconfigured API keys without proven business impact.
  • Verbose error and log messages that do not reveal personal data or secrets.
  • Clickjacking attacks with low or no impact.
  • Version disclosure without PoC on how it can be exploited.
  • Open ports without PoC on how it can be exploited.
  • Weak SSL configurations and SSL/TLS scan reports.
  • Arbitrary file upload without proof of the existence of the uploaded file.
  • Best practices violations (password complexity, expiration, re-use, etc.), with low or no impact.
  • Installation of malicious software on machines running Checkmk or on the Checkmk appliances.
  • Physical attacks against the Checkmk appliances.
  • Social engineering attacks against tribe29's employees, partners, or customers (e.g., phishing, vishing, waterholing, typosquatting, homograph attacks, etc.).
  • Anything related to email spoofing, SPF, DMARC or DKIM.
  • Email bombing.
  • Side-channel attacks.