Zabbix Frontend EUVD-2026-92397

Requires an authenticated Zabbix frontend account with read access to hosts (PR:L); exploitation is performed through the standard Host search feature by filtering on non-displayed credential fields (stored IPMI and PSK values). No user interaction with a victim is needed (UI:N). Limiting factors: the attacker must already be a valid, if low-privileged, Zabbix user; disclosure is indirect (a guess-confirmation oracle, not direct read), so recovering high-entropy PSK secrets is time-consuming and may be impractical, whereas short or weak IPMI passwords are realistically recoverable. Vendor vector marks the access as adjacent (AV:A), though the web-based frontend may in practice be reachable over the wider network.

This is a moderate-severity information-disclosure flaw (vendor CVSS 4.0 base 5.1) best characterized as an oracle/observable-discrepancy weakness (CWE-204): an authenticated low-privilege user (PR:L) can filter the host search on non-displayed fields - including stored IPMI and PSK credentials - and infer whether a guessed value is correct from the presence/absence of results. No EPSS score, CISA KEV listing, or public POC was provided, so there is no evidence of active exploitation or widespread automated attack interest; exploitation status is best treated as no public exploit identified at time of analysis. The practical risk is real but bounded: it requires an existing authenticated account with read access and is a guess-and-confirm channel rather than direct credential dump, so extracting a high-entropy PSK is slow and may be infeasible, while weak or short IPMI passwords are far more exposed. One notable signal conflict: the vendor vector uses AV:A (adjacent), but the Zabbix frontend is a web application typically reachable over the broader network, which would argue for AV:N - verify the intended access scope with the vendor, as it materially changes who can reach the endpoint. Overall this is a genuine but lower-priority hardening issue for most defenders - not a drop-everything critical - unless weak IPMI/PSK secrets are known to be in use.

A user holding a low-privilege Zabbix account with read access to hosts repeatedly submits host-search queries that filter on the hidden IPMI or PSK credential field, varying the guessed value. By observing whether each query returns the host or no result, they confirm correct guesses character-by-character or value-by-value, ultimately reconstructing stored credentials they were never authorized to view. No public exploit code was provided, but the technique requires only the standard search UI and an authenticated session.