CVE-2026-23937 in Zabbix
Summary
by MITRE • 08/18/2026
The Zabbix API host.get action can be exploited by authenticated users to extract a host's PSK key leading to potential loss of data integrity.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in the Zabbix monitoring platform centers on an improper restriction within the host.get method of its application programming interface, which allows authenticated users with specific permissions to retrieve sensitive cryptographic material associated with monitored hosts. Specifically, this flaw enables the extraction of Pre-Shared Keys used for TLS encryption between the Zabbix server and proxy or agent components. While access to the API requires authentication, the design oversight permits these credentials to be exposed in plaintext within the response payload when querying host details, thereby undermining the confidentiality guarantees intended by the system's security architecture.
From a technical perspective, this issue represents a classic case of sensitive information exposure through an insecure direct object reference or insufficient authorization checks on specific data fields. The API endpoint fails to mask or exclude the PSK field from standard read operations performed by users who have permission to view host configurations but should not necessarily possess the ability to export cryptographic secrets. This discrepancy arises because the system does not adequately distinguish between configuration visibility and credential management privileges, allowing a broader set of actors than intended to access high-value assets that are critical for maintaining secure communications within the monitoring infrastructure.
The operational impact of this vulnerability is significant as it directly compromises data integrity and confidentiality across the monitored environment. An attacker who obtains valid credentials with read-only or similar low-level permissions can leverage this flaw to harvest PSKs from multiple hosts without triggering additional security alerts typically associated with administrative actions like user creation or configuration changes. Once these keys are acquired, they can be used to impersonate legitimate Zabbix agents or proxies, allowing the injection of false metrics into the monitoring system or facilitating man-in-the-middle attacks against encrypted traffic channels. This undermines trust in the integrity of collected performance data and potentially exposes other network segments if the same credentials are reused elsewhere.
This vulnerability aligns with CWE-200, which classifies it as an Information Exposure Vulnerability where security-sensitive information is disclosed without proper access controls. Furthermore, within the context of the MITRE ATT&CK framework, this behavior corresponds to T1539, Steal Web Session Cookie, although adapted for API keys and cryptographic material rather than session tokens, falling under broader credential theft tactics such as T1078 Valid Accounts combined with data exfiltration techniques. The exploitation path is straightforward once initial access is established via valid credentials, making it a high-risk issue for environments relying on Zabbix for critical infrastructure monitoring where automated alerts depend heavily on the accuracy of incoming data streams.
Mitigation strategies should prioritize immediate patching to the latest version of Zabbix that addresses this API restriction by ensuring PSK fields are masked or excluded from standard host retrieval responses unless explicitly requested through a dedicated, highly privileged endpoint with enhanced logging and audit trails. Administrators must also enforce strict role-based access control policies, limiting who can query host details to only those roles that absolutely require such information for operational purposes. Additionally, rotating all affected PSKs immediately upon patching is essential to invalidate any keys potentially harvested during the window of exposure. Long-term remediation should involve implementing API gateway controls or WAF rules that monitor for anomalous patterns in credential retrieval and enforcing multi-factor authentication for administrative interfaces to reduce the attack surface available to potential adversaries seeking to exploit this flaw.