Is CVE-2022-23134 (Zabbix Frontend Improper Access Control) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-23134 to its Known Exploited Vulnerabilities catalogue on 22 February 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Malicious actors can pass step checks and potentially change the configuration of Zabbix Frontend. Any organisation running the affected product should treat remediation as urgent.

How CISA evidence changes the answer

For CVE questions, the operational question is not whether a flaw exists, but whether there is evidence that it is being used offensively right now. CISA’s KEV catalogue is the fastest reliable signal for that determination, because inclusion means the vulnerability has met CISA’s active-exploitation threshold and should be treated as a live exposure, not a theoretical one.

That distinction matters because exploited-in-the-wild issues move from “patch when convenient” to “reduce exposure immediately.” In practice, this means the first decision is exposure confirmation: determine whether the Zabbix Frontend is present, whether the affected frontend component is reachable, and whether any compensating control is actually restricting the vulnerable path.

When the issue is already in KEV, teams should assume attacker interest is real even if they have not yet seen alerts. The useful question becomes how far an attacker could progress if they reached the frontend, especially where configuration changes or administrative actions are possible through the vulnerable path.

What the weakness means operationally

Improper access control is dangerous because it breaks the trust boundary that should separate ordinary users from administrative or configuration-changing functions. If a step check can be bypassed, the flaw may allow an attacker to perform actions the application intended to reserve for a higher-privilege session.

That creates two practical concerns. First, the immediate impact may be unauthorized configuration changes, which can alter monitoring behaviour, suppress alerts, or redirect data. Second, a weak access check can be a foothold for broader compromise if the frontend is integrated with credentials, API endpoints, or internal administration functions that assume the frontend has already enforced authorization correctly.

In this kind of issue, the exploit path is often simpler than defenders expect: an attacker does not need to defeat the whole platform, only the control that was supposed to decide who may take a sensitive action. That makes access-control flaws especially attractive in exposed web management interfaces.

What to do before and after patching

Start by confirming whether any Zabbix Frontend instance is exposed to untrusted networks and whether the vulnerable workflow is reachable from accounts or sessions that should not have configuration rights. The next step is to apply the vendor fix or mitigation from the product advisory, then verify that the affected access path no longer allows the sensitive action.

If patching must wait, narrow exposure rather than relying on hope: restrict access to the frontend, remove unnecessary administrative reachability, and monitor the relevant configuration actions closely. If the product is internet-facing or broadly reachable inside the network, treat delay as a higher-risk exception, not a normal maintenance window.

After remediation, check for signs that the flaw may already have been used. That means reviewing configuration history, administrator actions, authentication logs, and any changes to hosts, scripts, media types, or notification settings that would let an attacker quietly reduce visibility or redirect alerts. If suspicious changes are found, rotate credentials or API material that could have been exposed through the interface and reset sessions for privileged users.

Risk and Threat Considerations

Because this CVE is confirmed as actively exploited, the main risk is not just service compromise, but silent control-plane abuse. A Zabbix frontend vulnerability can let an attacker change monitoring behaviour before defenders realise the interface was used maliciously.

Failure mechanism: An access-control failure in a web management path allows a lower-privilege actor to pass step checks and reach functions that should have been blocked, enabling unauthorized configuration changes or related administrative abuse.

Impact: Attackers may suppress alerts, alter monitoring logic, or use the interface as a stepping stone to broader compromise, which can delay detection and increase recovery cost.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Confines who can reach sensitive Zabbix functions.
	AU-6 — Audit Review, Analysis, and Reporting	Supports checking logs for earlier misuse after exploitation.
	SI-2 — Flaw Remediation	Directly addresses urgent remediation of an actively exploited vulnerability.
Recommendation — Restrict configuration-changing actions to the minimum necessary roles. Review frontend and admin logs for unauthorized configuration changes. Prioritise and verify remediation for the exploited Zabbix flaw.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Relevant to hardening the frontend and reducing exposure before patching.
	CIS-6 — Access Control Management	Maps to restricting sensitive administrative access paths in the frontend.
Recommendation — Harden the exposed frontend and remove unnecessary reachability. Limit who can perform privileged configuration actions.

Practitioner Guidance

What to prioritise: Treat exposed management interfaces as the highest-value remediation target when a KEV-listed flaw affects them. If the frontend is reachable beyond a tightly controlled admin network, exposure reduction should move ahead of routine backlog work.

What to verify: Confirm that the vulnerable action path is no longer reachable after fixing, and that only intended administrative roles can perform configuration-changing operations. A patch is not enough if compensating access controls still leave the same sensitive workflow open.

Practitioner takeaway: For an actively exploited access-control flaw, the real objective is to close the privileged action path and then prove that no earlier misuse remains hidden in configuration or audit history.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org