When Zabbix Agent was installed on Windows into a custom installation directory, the installer did not verify whether the selected directory had secure access permissions. If the target directory allowed unauthorized users to modify its contents, an attacker could place a malicious DLL that could later be loaded by the application, resulting in DLL sideloading. The installer has been hardened to detect potentially unsafe installation directories and now requires explicit user confirmation before proceeding with installation in such locations. This reduces the risk of accidental installation into directories with inappropriate permissions while preserving compatibility with existing deployment scenarios.
An authenticated administrator is able to crash Zabbix server or proxy by creating specifically crafted preprocessing/script item JavaScript scripts, leading to potential 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 is able to read out of bounds memory by utilizing a flaw in script item/preprocessing (JavaScript) HttpRequest logic, leading to potential confidentiality loss.
An authenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend validate.api.exists action, leading to potential denial of service.
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.
The frontend validatate.api.exists action can be exploited by authenticated users to extract plaintext user macro values leading to potential loss of confidentiality.
An unauthenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend popup.testtriggerexpr action, leading to potential denial of service.
Prototype pollution vulnerability in searchParamsToObject() is leading to a persistent XSS in Maps. URL parameter processing was not filtering dangerous properties like proto, combined with jQuery's unsafe element creation that traversed the prototype chain.
Zabbix API and Frontend login lockout mechanism has a flaw where several unsuccessful login requests are not properly counted towards the block counter if sent simultaneously, potentially allowing for more password guesses than intended.
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 Item history widget (in Zabbix 7.0+) or the Plain text widget (in Zabbix 6.0) can execute injected JavaScript when HTML display is enabled. This can allow an attacker to perform unauthorized actions depending on which user opens a dashboard containing these widgets. The malicious JavaScript would have to come from a monitored host controlled by the attacker. Note: the Item history widget is a replacement for the Plain text widget since Zabbix 7.0.
A user able to connect to Agent 2 can inject an Oracle TNS connection string via the 'service' parameter. This can lead to Agent 2 connecting to an attacker-controlled server and leaking Oracle database credentials if they are saved in a named session.
An authenticated (non-super) administrator can create a maintenance period with a JavaScript payload that is executed by any user that opens tooltip for that maintenance period in the Host navigator widget. This can allow the attacker to perform unauthorized actions depending on which user opens the tooltip.
Zabbix Agent 2 Docker plugin does not properly sanitize the 'docker.containerinfo' parameters when forwarding them to the Docker daemon. An attacker capable of invoking Agent 2 can read arbitrary files from running Docker containers by injecting them via the Docker archive API.
An unauthenticated attacker can exploit the Frontend 'validate' action to blindly instantiate arbitrary PHP classes. The impact depends on environment setup but appears limited at this time.
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.
Host and event action script input is validated with a regex (set by the administrator), but the validation runs in multiline mode. If ^ and $ anchors are used in user input validation, an injected newline lets authenticated users bypass the check and inject shell commands.
For performance reasons Zabbix Server/Proxy reuses JavaScript (Duktape) contexts (used in script items, JavaScript reprocessing, 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 that makes the built in Zabbix JavaScript objects read-only, but please be advised that usage of global JavaScript variables is not recommended because their content could be leaked. More information <a href='https://www.zabbix.com/documentation/7.4/en/manual/installation/knownissues#preprocessing-global-variables-are-unsafe'>in Zabbix documentation</a>.
An authenticated Zabbix user (User role) with template/host write permissions is able to create objects via the configuration.import API. This can lead to confidentiality loss by creating unauthorized hosts. Note that the User role is normally not sufficient to create and edit templates/hosts even with write permissions.
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 Zabbix adminitrator can inject arbitrary SQL during the autoremoval of hosts by inserting malicious SQL in the 'Visible name' field.
Zabbix Agent 2 smartctl plugin does not properly sanitize smart.disk.get parameters, allowing an attacker to inject unexpected arguments into the smartctl command. In Zabbix 5.0 this allows for remote code execution.
The cause of vulnerability is improper validation of form input field “Name” on Graph page in Items section.
An unauthenticated user can create a link with reflected Javascript code inside the backurl parameter and send it to other authenticated users in order to create a fake account with predefined login, password and role in Zabbix Frontend.
After the initial setup process, some steps of setup.php file are reachable not only by super-administrators, but by unauthenticated users as well. Malicious actor can pass step checks and potentially change the configuration of Zabbix Frontend.
In the case of instances where the SAML SSO authentication is enabled (non-default), session data can be modified by a malicious actor, because a user login stored in the session was not verified. Malicious unauthenticated actor may exploit this issue to escalate privileges and gain admin access to Zabbix Frontend. To perform the attack, SAML authentication is required to be enabled and the actor has to know the username of Zabbix user (or use the guest account, which is disabled by default).
Zabbix Server 2.2.x and 3.0.x before 3.0.31, and 3.2 allows remote attackers to execute arbitrary code.
Zabbix before 5.0 represents passwords in the users table with unsalted MD5.