Zabbix vulnerabilities

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.

The Perl SNMP trap receiver script shipped with Zabbix does not properly neutralize the ZBXTRAP record delimiter in trap content. Someone able to send SNMP traps can inject a record targeting another host, resulting in a loss of integrity.

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.

The frontend validate.api.exists action can be exploited by authenticated users to extract plaintext user macro values, leading to potential loss of confidentiality.

An unauthenticated user can cause disproportionate CPU load on the Frontend webserver by sending specially crafted requests to the popup.testtriggerexpr action, leading to potential denial of service.

The email media OAuth field 'Client secret' cannot be read after saving, but a Super Admin can leak it by setting a malicious 'Token endpoint'. Changes were made to reset the client secret upon changing the token endpoint.

The login lockout mechanism in Zabbix API and Frontend has a flaw where several unsuccessful login requests sent simultaneously are not properly counted towards the block counter, potentially allowing more password guesses than intended.

A low-privilege Zabbix user with API access can exploit a blind SQL injection vulnerability in include/classes/api/CApiService.php to execute arbitrary SQL selects via the sortfield parameter. Although query results are not returned directly, an attacker can exfiltrate arbitrary database data through time-based techniques, potentially leading to session identifier disclosure and administrator account compromise.

Input validation for host and event action scripts in Zabbix uses regex (set by the administrator) but runs in multiline mode. If ^ and $ anchors are used, an injected newline lets authenticated users bypass the check and inject shell commands.

For performance reasons Zabbix Server/Proxy reuses JavaScript (Duktape) contexts in script items, JavaScript reprocessing, and Webhooks. This can lead to confidentiality loss where a regular (non-super) Zabbix administrator leaks data for hosts they do not have access to. A fix has been released making built-in Zabbix JavaScript objects read-only, but usage of global JavaScript variables is not recommended.

An authenticated Zabbix user (including Guest) is able to cause disproportionate CPU load on the webserver by sending specially crafted parameters to /imgstore.php, leading to potential denial of service.

An authenticated Zabbix Super Admin can exploit the oauth.authorize action to read arbitrary files from the webserver, leading to potential confidentiality loss.

A vulnerability in Zabbix allows a regular user without permission to the Monitoring -> Problems view to call the problem.view.refresh action and retrieve a list of active problems.

A regular Zabbix user can search other users in their user group via Zabbix API by selecting fields the user does not have access to view. This allows data-mining some field values the user does not have access to.

A Zabbix administrator can inject arbitrary SQL during the autoremoval of hosts by inserting malicious SQL in the 'Visible name' field.

Due to a bug in the Zabbix API, the hostprototype.get method lists all host prototypes to users that do not have any user groups assigned to them. This may lead to unauthorized disclosure of host prototype information.