Summary
CVE-2026-92882 describes an insufficiently protected credentials vulnerability in the host and folder configuration endpoints of the REST API in Checkmk. An authenticated user who has permission to view a host’s configuration can read stored SNMP community strings, SNMPv3 authentication and privacy pass phrases, and IPMI passwords in clear text from GET responses. Notably, the Checkmk setup GUI never displays these sensitive values, meaning the REST API exposes data that is intentionally hidden in the normal administrative interface.
Technical Analysis
The vulnerability is classified under CWE-522, which refers to insufficiently protected credentials. In this case, Checkmk stores sensitive credential material—specifically SNMP community strings, SNMPv3 authentication and privacy pass phrases, and IPMI passwords—as part of host and folder configuration objects. When an authenticated user queries the host or folder configuration endpoints of the REST API via a GET request, the response includes these credentials in clear text rather than masking, redacting, or encrypting them.
The CVSS 4.0 base score for this vulnerability is 5.3, placing it in the MEDIUM severity category. The full vector string is CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:L/SA:L. Breaking this down: the attack vector is network-based (AV:N), meaning the vulnerability can be exploited remotely. The attack complexity is low (AC:L), and no special conditions are required (AT:N). The attacker needs low privileges (PR:L), meaning any authenticated user with basic access can potentially exploit this. No user interaction is required (UI:N). The vulnerability class is CWE-522, insufficiently protected credentials.
The key issue is a design inconsistency between the setup GUI and the REST API. The setup GUI is designed to never display these sensitive credential values, presumably to protect them from shoulder-surfing or casual exposure. However, the REST API endpoints that return the same configuration data do not apply the same protection. This means that any user who can call the GET endpoint for a host or folder configuration will receive the full configuration object, including credentials that would normally be hidden in the GUI.
The vulnerability affects multiple versions of Checkmk, specifically versions prior to the patched releases. The affected versions include Checkmk <2.5.0p15, <2.4.0p37, <2.3.0p51, and 2.2.0 which is end-of-life (EOL). This broad range of affected versions indicates that the vulnerability has been present for a significant period across multiple major release lines.
Affected Software and Versions
- Checkmk <2.5.0p15 — affected by the vulnerability
- Checkmk <2.4.0p37 — affected by the vulnerability
- Checkmk <2.3.0p51 — affected by the vulnerability
- Checkmk 2.2.0 (EOL) — affected by the vulnerability and no longer receiving updates
Users running any of these versions should upgrade to the patched release for their respective branch: 2.5.0p15, 2.4.0p37, or 2.3.0p51. Users on the 2.2.0 branch, which is end-of-life, should migrate to a supported branch as no patches will be issued for EOL versions.
Impact
The impact of this vulnerability is primarily related to confidentiality of stored credentials. An authenticated attacker with the ability to view host configurations can retrieve sensitive monitoring credentials in clear text. These credentials include:
- SNMP community strings — used for SNMP v1/v2c authentication, these strings grant access to network device information and, depending on the community string’s permissions (read-write), could allow configuration changes on network devices.
- SNMPv3 authentication pass phrases — used for authenticating SNMPv3 requests, these pass phrases are part of the User Security Model (USM) and their exposure could allow an attacker to forge authenticated SNMPv3 queries.
- SNMPv3 privacy pass phrases — used for encrypting SNMPv3 traffic, exposure of these pass phrases could allow an attacker to decrypt intercepted SNMPv3 communications.
- IPMI passwords — used for Intelligent Platform Management Interface authentication, these passwords grant access to baseboard management controllers (BMCs) which provide out-of-band management of servers. Exposure could allow an attacker to gain remote management access to physical servers.
The CVSS vector indicates low impact on both the vulnerable system’s confidentiality (VC:L) and the subsequent system’s confidentiality and integrity (SC:L/SI:L). While the impact is rated as low, the real-world severity depends heavily on what credentials are stored in the exposed configurations and what systems those credentials provide access to. In environments where SNMP community strings or IPMI passwords provide access to critical infrastructure, the practical impact could be significantly higher than the CVSS score suggests.
It is important to note that exploitation requires authentication (PR:L). The attacker must already have a valid account with permissions to view host configurations. This limits the attack surface to authenticated users, but in environments with broad access policies or where many users have read access to configurations, the risk is amplified.
Exploitation Scenario
An attacker who has obtained authenticated access to a Checkmk instance—whether through legitimate access, compromised credentials, or an internal position—can exploit this vulnerability by sending GET requests to the host or folder configuration endpoints of the REST API. The response will include the full configuration object for the requested host or folder, including any stored SNMP community strings, SNMPv3 pass phrases, and IPMI passwords in clear text.
For example, an attacker with basic read access to monitoring configurations could enumerate all hosts configured in Checkmk by querying the REST API. For each host that has SNMP or IPMI credentials configured, the GET response would expose those credentials. The attacker could then use these credentials to directly access the monitored devices, potentially gaining deeper access to the network infrastructure.
The scenario is particularly concerning in multi-tenant or large enterprise environments where Checkmk is used to monitor a wide range of devices. A user who is only intended to have visibility into monitoring status could inadvertently or maliciously access the raw credentials used for monitoring, bypassing the intended access controls that the setup GUI enforces by hiding these values.
Additionally, because the setup GUI never displays these values, administrators may not be aware that the REST API exposes them differently. This creates a false sense of security—administrators may believe that credentials are adequately protected because they are hidden in the GUI, without realizing that the API provides a different exposure path.
Detection and Mitigation
Detection
To detect potential exploitation of this vulnerability, administrators should monitor REST API access logs for GET requests to host and folder configuration endpoints. Look for patterns such as:
- Unusual or bulk GET requests to host configuration endpoints from a single user or IP address
- GET requests from users who do not normally access configuration data via the API
- Automated or scripted access patterns that suggest enumeration of host configurations
Checkmk’s audit logs may also provide visibility into API access. Administrators should review which users have API access and whether their usage patterns align with expected behavior.
Mitigation
- Upgrade immediately — Update to the patched version for your branch: Checkmk 2.5.0p15, 2.4.0p37, or 2.3.0p51. Users on 2.2.0 (EOL) should migrate to a supported branch.
- Restrict API access — Review and limit which users have access to the REST API, particularly to configuration endpoints. Apply the principle of least privilege.
- Audit credential exposure — Review which hosts have SNMP and IPMI credentials stored in Checkmk and assess the risk if those credentials were exposed. Consider rotating credentials that may have been exposed prior to patching.
- Monitor API usage — Implement logging and alerting on API access to configuration endpoints to detect suspicious activity.
- Review user permissions — Ensure that users who only need to view monitoring status do not have unnecessary access to configuration data via the API.
Bug Bounty Angle
This vulnerability highlights a common class of issues that bug bounty hunters should look for: inconsistencies between different interfaces that expose the same data. In this case, the setup GUI properly hides sensitive credentials, but the REST API does not apply the same protection. This type of vulnerability is often found by:
- Comparing the data returned by different interfaces (GUI vs. API, different API endpoints, export functions, etc.) for the same underlying object
- Looking for fields that are masked or redacted in one interface but fully exposed in another
- Testing API endpoints that return configuration objects for sensitive fields that should be protected
- Examining whether read-only or low-privilege access paths expose data that should require elevated privileges
For researchers testing monitoring and management platforms like Checkmk, credential storage and exposure is a particularly fruitful area. These systems inherently store credentials for connecting to monitored devices, and the way those credentials are protected across different access paths can vary significantly. The key insight is that protecting credentials in one interface does not guarantee protection in all interfaces—each access path must be independently evaluated.
The CWE-522 classification (insufficiently protected credentials) is a broad category that encompasses various failures to adequately protect stored credentials. Researchers should look for credentials stored in clear text, credentials returned in API responses without masking, credentials included in log files, and credentials exposed through export or backup functionality.
Frequently Asked Questions
What versions of Checkmk are affected by CVE-2026-92882?
The vulnerability affects Checkmk versions <2.5.0p15, <2.4.0p37, <2.3.0p51, and 2.2.0 (EOL). Users should upgrade to 2.5.0p15, 2.4.0p37, or 2.3.0p51 depending on their branch, or migrate from 2.2.0 to a supported branch.
What credentials are exposed through this vulnerability?
The vulnerability exposes SNMP community strings, SNMPv3 authentication and privacy pass phrases, and IPMI passwords in clear text through GET responses from the host and folder configuration REST API endpoints.
Does the Checkmk setup GUI display these credentials?
No. The setup GUI never displays these sensitive values. The vulnerability exists because the REST API does not apply the same protection as the GUI, exposing the credentials in clear text in GET responses.
Leave a Reply