CVE-2026-59787

In Zabbix 7.4 the cryptographic key used for signing Frontend sessions has been erroneously written to the database seed. Currently the only known exploitation scenario is for deployments that utilize both - SAML authentication and guest users. In such cases the key can be used to forge valid session cookies, potentially leading to unauthorized access. For other Zabbix deployments this does not have a known impact.

Zabbix before 2.2.14 and 3.0 before 3.0.4 has an SQL injection vulnerability that allows remote attackers to execute arbitrary SQL commands via the toggle_ids array parameter in latest.php.

The email media type OAuth form passes the Authorization endpoint value to window.open() without validating the URL scheme, so a javascript: URL is executed in the browser. A crafted media type configuration, deliverable as an import file, runs arbitrary JavaScript as the Super Admin who grants consent.

Zabbix Server and Proxy accept the active agent heartbeat message regardless of the configured PSK or certificate authentication. Someone with access to the Zabbix trapper port can report an arbitrary host using an active agent as available, resulting in a loss of integrity.

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.

The JavaScript preprocessing (Duktape) engine on Zabbix server has a vulnerability where a limited administrator is able to read raw heap data potentially resulting in leaked data from other running preprocessors not available to said administrator.

An authenticated administrator can crash Zabbix server or proxy by creating specially crafted preprocessing/script item JavaScript scripts, leading to denial of service.

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.

A Zabbix administrator can read out-of-bounds memory by exploiting a flaw in the HttpRequest logic of script items/preprocessing (JavaScript), leading to potential confidentiality loss.

An authenticated user can cause disproportionate CPU load on the Frontend webserver by sending specially crafted requests to the validate.api.exists action, leading to potential denial of service.