CVE-2024-42327

What it actually does

The vulnerability is an authenticated SQL injection in the Zabbix frontend API. A non-administrative user with the default User role, or any role that permits API access, can call the CUser.get API path, which invokes CUser::addRelatedObjects and improperly incorporates attacker-controlled input into a SQL query. Successful exploitation can allow the attacker to manipulate backend database queries, potentially read data outside the caller’s authorized scope, extract sensitive Zabbix configuration or credentials, enumerate users, obtain password hashes or tokens, and in some database/application configurations modify data or escalate privileges within Zabbix.

Why it matters to the business

A low-privileged Zabbix account can become a path to compromise the monitoring platform and the sensitive operational data it stores. Because Zabbix often contains infrastructure inventory, host metadata, alerting rules, credentials, tokens, and integration secrets, exploitation can expose information useful for broader network intrusion and operational disruption. The issue has public exploit availability, a high EPSS score of 0.78831, and has been public for a long time, making internet-facing or broadly accessible Zabbix frontends particularly urgent to review even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first obtains valid Zabbix frontend/API credentials for any account with API access, which may be a default low-privilege user, a phished account, a reused credential, or a token from another compromise. The attacker authenticates to the Zabbix API endpoint and sends a crafted JSON-RPC request invoking user.get. Malicious input is placed in parameters that cause CUser.get to request related objects, triggering the vulnerable CUser::addRelatedObjects SQL construction. The attacker then uses error-based, boolean-based, or time-based SQL injection behavior to confirm the flaw and extract database content. After collecting sensitive information such as user records, session or token material, configuration secrets, monitoring targets, and integration details, the attacker may pivot to Zabbix administrator access, tamper with monitoring configuration, suppress alerts, or use discovered infrastructure data to support further intrusion.

How to fix it

Upgrade Zabbix to a fixed version that includes the upstream fix for the vulnerable CUser::addRelatedObjects SQL construction. For source/GIT-based deployments, ensure commit 0543fbe4af6b9833aba9005540c1544272499225 or an equivalent vendor-maintained fix is present. Apply the fix to every Zabbix frontend node, not just the server component, because exploitation occurs through the frontend API. If immediate patching is not possible, reduce exposure by restricting access to the Zabbix frontend/API to trusted networks, disabling or tightly limiting API access for non-administrative roles where operationally feasible, enforcing MFA for frontend access, rotating API tokens, and reviewing low-privilege accounts that do not need API access. After patching, rotate credentials and tokens if exploitation is suspected.

How to confirm the fix worked

Confirm the deployed Zabbix code or package contains the fix for commit 0543fbe4af6b9833aba9005540c1544272499225 or a vendor release that incorporates it. Verify all frontend instances are updated consistently, including containers, standby nodes, and manually built deployments. Review Zabbix role configuration to ensure only intended users have API access. From an application-testing perspective, authenticated calls to user.get with malformed related-object parameters should be rejected or handled safely and should not generate SQL errors, timing anomalies, or unexpected data disclosure. Validate web access controls by confirming /api_jsonrpc.php is not reachable from untrusted networks unless explicitly required.

Typical attack path

1. Identify an exposed or reachable Zabbix frontend/API endpoint, commonly /api_jsonrpc.php.
2. Obtain valid credentials or an API token for any Zabbix user role that permits API access.
3. Authenticate to the Zabbix API using JSON-RPC.
4. Send crafted user.get requests that exercise related-object handling in CUser::addRelatedObjects.
5. Use SQL injection responses, errors, or timing differences to verify database query manipulation.
6. Extract sensitive database content such as user records, hashes, tokens, configuration, host inventory, and integration secrets.
7. Use recovered data to escalate privileges in Zabbix, tamper with monitoring, or pivot to monitored systems and connected services.

How to detect it

Investigate Zabbix frontend web server logs, reverse proxy/WAF logs, Zabbix audit logs, API access logs if enabled, PHP error logs, and database logs. Focus on authenticated POST requests to /api_jsonrpc.php that invoke the user.get method, especially from unusual IP addresses, unexpected user agents, non-human automation, newly created accounts, or low-privilege accounts that do not normally use the API. Because standard web logs often do not record JSON POST bodies, check WAF, API gateway, reverse proxy body logging, EDR network sensors, and database audit/error logs for SQL metacharacters, UNION/SELECT probes, time-delay functions, database catalog access, or repeated malformed user.get requests. Review database logs for SQL syntax errors or time-delay functions around the same timestamps as Zabbix API calls. In Zabbix itself, review audit events for new users, role changes, API token creation, configuration exports, disabled actions, changed media types, modified scripts, or monitoring changes following suspicious API activity. If exploitation is suspected, assume database-resident secrets may have been exposed and perform credential rotation and incident scoping.

• POST /api_jsonrpc.php
• "method":"user.get"
• "method": "user.get"
• "jsonrpc":"2.0"
• "jsonrpc": "2.0"
• "selectRole"
• "selectUsrgrps"
• "selectMedias"
• "selectMediatypes"
• "user.get"
• UNION SELECT
• UNION ALL SELECT
• information_schema
• pg_catalog
• mysql.user
• SLEEP(
• pg_sleep(
• BENCHMARK(
• WAITFOR DELAY
• extractvalue(
• updatexml(
• SQL syntax
• You have an error in your SQL syntax
• PostgreSQL query failed
• PDOException
• mysqli_sql_exception
• /api_jsonrpc.php

What your security team should do

• Prioritize patching because public exploit code is available and EPSS indicates high likelihood of exploitation.
• Inventory all Zabbix frontend/API endpoints, including internet-facing, VPN-accessible, containerized, and internally exposed instances.
• Upgrade or rebuild all affected Zabbix deployments so they include commit 0543fbe4af6b9833aba9005540c1544272499225 or the corresponding fixed vendor release.
• Restrict /api_jsonrpc.php access to trusted administrative networks or approved integrations.
• Audit Zabbix roles and remove API access from default or low-privilege users that do not require it.
• Review and rotate Zabbix API tokens, integration credentials, and privileged account passwords if suspicious API activity is found.
• Hunt historical logs for abnormal authenticated user.get calls, SQL error messages, timing probes, and bulk data enumeration.
• Enable or increase logging of API requests where feasible, while avoiding long-term storage of sensitive request bodies without proper controls.
• Monitor for post-exploitation behavior such as new administrator users, changed media scripts, modified actions, disabled alerts, suspicious tokens, and unexpected configuration exports.