CVE-2026-59785 in Zabbix
Summary
by MITRE • 10/05/2026
Host search in Frontend allows filtering by fields that are not displayed, including stored IPMI and PSK credentials. A user with read access can guess a credential and see from the search result whether the guess was right, letting them uncover it.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability described constitutes an information disclosure flaw within the frontend host search functionality of the affected system. This issue arises because the filtering mechanism for searching hosts is not strictly bound to the fields that are visually rendered or exposed in the user interface. Instead, the backend query engine processes filter criteria against a broader set of database attributes than what is intended for public consumption. Specifically, this includes sensitive security credentials such as Intelligent Platform Management Interface IPMI passwords and Pre-Shared Keys PSKs used for authentication between components. While these fields are not displayed in standard views or search result summaries, they remain accessible via the underlying API endpoints that power the search functionality when specific filter parameters are supplied by a client request.
From an operational perspective, this architectural oversight creates a significant security risk through what is known as a side-channel attack vector. An attacker with read-only access to the host management interface can exploit this discrepancy by constructing targeted queries that include these hidden credential fields in their search filters. The system does not validate whether the requesting user has permission to view or verify the contents of these specific attributes before processing the filter condition. Consequently, when a user submits a query containing a guessed value for an IPMI password or PSK, the backend evaluates this guess against the stored values and returns results based on the match status. If the search yields hosts matching the criteria, it confirms that the guessed credential is correct; if no matches are found, the guess was incorrect. This binary feedback loop allows an attacker to iteratively brute-force sensitive credentials without triggering typical authentication failure logs or rate-limiting mechanisms associated with direct login attempts.
This vulnerability aligns closely with CWE-209 Generation of Error Message Containing Sensitive Information and CWE-778 Insufficient Initial Visibility, as it exposes internal system states through logical inference rather than direct data retrieval. In the context of the MITRE ATT&CK framework, this behavior facilitates Credential Access via T1552 Unsecured Credentials, specifically leveraging the discovery phase to enumerate valid secrets. The ability to verify credentials without explicit authentication steps bypasses standard security controls designed to protect stored secrets and undermines the principle of least privilege by allowing read-only users to effectively perform credential guessing attacks against administrative or service-level accounts embedded in host configurations.
The impact of this vulnerability is severe, as IPMI credentials often provide out-of-band remote access to physical servers, granting attackers low-level control over hardware settings, including power state management and firmware updates. Similarly, PSKs are critical for securing communication channels between infrastructure components; their compromise can lead to man-in-the-middle attacks or unauthorized configuration changes across the network. An attacker who successfully enumerates these credentials can pivot from a limited web interface account to full system control, potentially leading to data exfiltration, ransomware deployment, or persistent backdoor installation that is difficult to detect through standard monitoring tools focused on application-layer activity rather than infrastructure-level interactions.
Mitigation strategies must address both the immediate exposure and the underlying architectural flaw. The most effective remediation involves ensuring that search filter parameters are strictly validated against a whitelist of fields explicitly permitted for querying based on the user's role and permissions. Any attempt to query hidden or sensitive attributes like IPMI passwords or PSKs should be rejected with a generic error message indicating invalid input, rather than returning filtered results that leak existence information. Additionally, implementing rate limiting on search endpoints can mitigate brute-force attempts even if other controls are bypassed. From a defense-in-depth perspective, organizations should audit their frontend-backend contract definitions to ensure data masking policies are enforced at the API layer for all sensitive fields, regardless of whether they are displayed in the UI. Regular security assessments and penetration testing focused on logic flaws in search and filtering mechanisms can help identify similar vulnerabilities before they are exploited by malicious actors seeking lateral movement or privilege escalation within managed infrastructure environments.