Safeguard
Vulnerability Analysis•

CVE-2026-23930: High Zabbix Frontend CPU Denial of Service

CVE-2026-23930 lets an unauthenticated user drive up CPU on the Zabbix frontend through popup.testtriggerexpr. Upgrade to 6.0.47, 7.0.27 or 7.4.11.

Safeguard Security Team
3 min read

CVE-2026-23930 is a resource consumption flaw in the Zabbix frontend. An unauthenticated user can send crafted requests to the popup.testtriggerexpr action and cause heavy CPU load on the web server. The record scores it 7.5 (High), while Zabbix rates it 5.3 (Medium). Fixed versions are 6.0.47, 7.0.27 and 7.4.11.

What's affected

Zabbix's tracker entry ZBX-28069 lists these affected versions: 6.0.0 to 6.0.46, 7.0.0 to 7.0.26, and 7.4.0 to 7.4.10. The fixed versions are 6.0.47, 7.0.27 and 7.4.11. The tracker lists no workaround and gives updating as the mitigation.

Source conflict to note: the CVE record scores 7.5 (High) using CVSS 3.1 with a network vector and no privileges. Zabbix scores 5.3 (Medium) using CVSS 4.0 with an adjacent vector and low availability impact. Both agree that only availability is affected. Pick the higher rating if your frontend is reachable from the internet, and the lower one if it sits on a management network.

Weakness class: CWE-405, asymmetric resource consumption.

How to check if you're exposed

In the Zabbix web interface, the version appears in the page footer and under Reports, System information. On the server, the zabbix_server binary reports its version with the -V flag. The frontend and server versions can differ, and this flaw is in the frontend, so read the frontend version.

Also check who can reach the frontend. If the web UI is exposed to the internet or to a large internal network, the flaw can be tried by anyone who can send an HTTP request. A reverse proxy log showing repeated requests that name popup.testtriggerexpr, especially from one address and alongside high CPU, is worth a look.

What to do now

  1. Upgrade the Zabbix frontend to 6.0.47, 7.0.27 or 7.4.11, whichever matches your release line.
  2. Restrict network access to the frontend to the networks that need it, using firewall rules or a VPN.
  3. Add request rate limiting at your reverse proxy for the frontend, which limits the damage from any request flood.
  4. Set an alert on web server CPU for the monitoring host itself, so you are told when your monitor is the thing under strain.
  5. If you cannot upgrade this week, record the exception and the compensating network limits.

Why it matters

This is a denial of service flaw in the tool you depend on to tell you when other things break. If an attacker can pin the web server's CPU with cheap requests, operators lose their view of the estate at the moment they may need it.

The weakness class is uncontrolled or asymmetric resource consumption: a small request makes the server do a large amount of work. Fixes usually bound the work or validate the input first. Unauthenticated reach is what makes it worth patching, even though confidentiality and integrity are not affected. The KEV flag is false and Zabbix does not report exploitation.

Try it yourself

Continuous monitoring is how you catch a dependency or product version drifting behind a fixed release. This demo walks through it.

Click through it at your own pace, or open it full screen.

Quick check

Does this expose monitoring data?

No. The record and Zabbix describe availability impact only.

Which rating should I use?

Both are reported above. Use the higher rating when the frontend is internet facing.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.