Cleartext credential exposure in the Checkmk GmbH Checkmk REST API

Insufficiently protected credentials in the host and folder configuration endpoints of the REST API in Checkmk <2.5.0p15, <2.4.0p38, <2.3.0p51 and 2.2.0 (EOL) allows an authenticated user who may view a host's configuration to read stored SNMP community strings, SNMPv3 auth and privacy pass phrases and IPMI passwords in clear text from GET responses, although the setup GUI never displays these values.

The affected and fixed boundaries supported by the vendor and supplied record are:

• Checkmk 2.5.0: affected below 2.5.0p15; the vendor lists 2.5.0p15 as fixed.
• Checkmk 2.4.0: affected below 2.4.0p38; the vendor lists 2.4.0p38 as fixed.
• Checkmk 2.3.0: affected below 2.3.0p51; the vendor lists 2.3.0p51 as fixed.
• Checkmk 2.2.0: affected and EOL; no separate fix for this branch is identified.
• The vendor also lists 3.0.0b1 as containing the fix, with that release marked not yet released in the advisory.

An aggregated record returned during research showed the 2.4.0p37 boundary, but that conflicts with the supplied affected facts and the direct vendor advisory. The 2.4.0p38 boundary is used because it is the vendor-confirmed value.

The Checkmk GmbH Checkmk REST API returned secret-bearing fields in GET responses from host and folder configuration endpoints instead of applying the redaction used by the setup GUI. The exposed data includes snmp_community, containing the SNMP v1/v2 community string and SNMPv3 auth_password and privacy_password pass phrases; management_snmp_community, containing the corresponding management-board values; and management_ipmi_credentials, containing the IPMI password. An attacker must be authenticated and permitted to view a host's configuration. The vendor states that an account with the built-in user role that is a contact for the host is sufficient. This is CWE-522, Insufficiently Protected Credentials, because the API disclosed stored secrets in clear text even though the setup GUI did not display them, including to administrators. The fix omits the secret fields from GET responses while retaining non-secret metadata such as type, auth_protocol, security_name, and privacy_protocol; the secret fields remain mandatory when creating or updating a host. The available evidence does not establish the internal storage implementation or the exact authorization decision used inside the affected code.

The vulnerability is reachable over the network through the REST API. Exploitation requires an authenticated account with permission to view a host's configuration, but does not require interaction from another user; the supplied record characterizes the required privilege as low and the attack complexity as low. The vendor confirms that access through the setup GUI is not required because the secrets are returned by configuration GET responses. The supplied record marks public_exploit as false, but that status is not proof that exploitation cannot occur. No exploit code, campaign, victim, or specific indicator is identified in the available evidence.

The primary technical outcome is unauthorized disclosure of credentials stored in host and folder configuration through REST API responses. The attacker must already have an authenticated account with permission to view host configuration, so the flaw is not anonymous access; however, the required privilege can be lower than administrator access. Exposed SNMP community strings, SNMPv3 pass phrases, and IPMI passwords could extend the impact to monitored or managed devices if they remain valid and grant useful rights.

The available evidence does not establish that the flaw directly enables data modification, privilege escalation, or loss of availability in Checkmk. The practical scope depends on the number of hosts visible to the account, which credential types are configured, the rights those credentials have on target devices, and whether the values have already been rotated.

The flaw can expose secrets used to monitor or manage network devices and infrastructure. If the disclosed credentials remain valid and have corresponding rights on the target systems, an attacker could potentially use them to access related devices or management interfaces; the actual reach depends on the permissions of each credential.

Operational consequences may include:

• Rotating SNMP community strings, SNMPv3 pass phrases, and IPMI passwords for affected hosts.
• Reviewing API access history, account permissions, and retained copies of responses that may have been logged or stored.
• Possible monitoring or management disruption if credentials are rotated before every dependent system has been updated.

The vulnerability is described as a secret-disclosure issue. The available evidence does not establish that it directly permits Checkmk configuration changes or service disruption.

1. Upgrade each deployment to the vendor-confirmed fixed release for its branch: 2.5.0p15, 2.4.0p38, 2.3.0p51, or 3.0.0b1, as applicable. Do not infer that every release after these points or every parallel branch has been verified unless the vendor explicitly covers it.
2. If running 2.2.0, plan migration to a supported branch because no fix for the EOL branch is identified in the available evidence.
3. Review API clients. After the update, secret fields are omitted from GET responses but remain mandatory when creating or updating a host, so clients that read a configuration and send it back unchanged may need to supply credentials explicitly.
4. If the API may have returned credentials, rotate the related SNMP community strings, SNMPv3 authentication and privacy pass phrases, and IPMI passwords. This is a precaution based on the data that may have been readable.
5. Review host-configuration permissions and remove unnecessary access, but do not treat access reduction as a substitute for applying the software fix.

1. Inventory Checkmk instances and identify deployments on the affected release branches described by the advisory.
2. Review which accounts can view host configuration, with particular attention to accounts using the built-in user role and accounts listed as contacts for affected hosts.
3. Review API audit logs, reverse proxy logs, and web logs for GET requests to host or folder configuration endpoints made by those accounts. The exact endpoint paths are not established by the available evidence and should not be guessed.
4. If API responses are retained, search for snmp_community, management_snmp_community, and management_ipmi_credentials, together with secret fields such as auth_password, privacy_password, and password.
5. If a response contained a secret, treat the credential as potentially exposed, rotate the related SNMP community string, SNMPv3 pass phrase, or IPMI password, and review the requesting account's activity.
6. These are defensive review steps rather than vendor-defined IOCs. The absence of matching logs does not establish that no secret was read.