CVE-2022-35229 in Zabbix
Summary
by MITRE • 07/06/2022
An authenticated user can create a link with reflected Javascript code inside it for the discovery page and send it to other users. The payload can be executed only with a known CSRF token value of the victim, which is changed periodically and is difficult to predict.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2025
This vulnerability represents a reflected cross-site scripting flaw that exists within the discovery page functionality of the affected application. The issue arises when an authenticated user can craft a malicious link containing javascript code that gets reflected back to other users who access the discovery page. The reflected nature of this vulnerability means that the malicious payload is not stored on the server but rather injected into the response dynamically based on user input parameters. This type of vulnerability falls under the CWE-79 category for cross-site scripting and aligns with the ATT&CK technique T1531 which focuses on establishing persistence through web shell or script injection methods.
The exploitation of this vulnerability requires a specific prerequisite that significantly limits its practical impact. An attacker must first obtain a valid CSRF token from a victim user, as the malicious payload can only execute successfully when the victim's browser makes a request with the correct token value. This CSRF token is designed to change periodically and is intentionally difficult to predict, making automated exploitation extremely challenging. The token-based protection mechanism demonstrates a security control that attempts to prevent unauthorized actions by requiring valid session tokens. However, this protection is bypassed when an authenticated user can manipulate the discovery page to execute code in the context of another user who has a valid session.
The operational impact of this vulnerability extends beyond simple data theft or session hijacking. When successfully exploited, the reflected javascript code can perform actions such as stealing session cookies, redirecting users to malicious sites, modifying page content, or even executing more sophisticated attacks like credential harvesting or browser fingerprinting. The authenticated nature of the initial access requirement means that the attacker must first compromise a legitimate user account, which could occur through various means such as credential theft, phishing attacks, or exploitation of other vulnerabilities in the authentication system. The periodic token changes create a moving target scenario that makes this vulnerability particularly difficult to exploit in practice, as the attacker would need to either predict or capture a valid token within its short window of validity.
Mitigation strategies for this vulnerability should focus on implementing comprehensive input validation and output encoding mechanisms throughout the discovery page functionality. The application should sanitize all user-provided input before rendering it in the response, implementing proper context-aware encoding for javascript, html, and css contexts. Additionally, the CSRF protection mechanism should be strengthened by implementing more robust token generation and validation processes that are resistant to prediction attacks. Implementing Content Security Policy headers can provide an additional layer of defense against reflected XSS attacks by restricting the sources from which scripts can be executed. The system should also consider implementing rate limiting and monitoring for suspicious link creation patterns, as well as providing user education about the risks of clicking unknown links in discovery or collaboration environments. From a defensive perspective, this vulnerability highlights the importance of defense-in-depth strategies where multiple security controls work together to protect against different attack vectors. The vulnerability demonstrates how even well-intentioned security controls like CSRF tokens can be bypassed when other weaknesses exist in the application's architecture, emphasizing the need for comprehensive security testing including both automated scanning and manual penetration testing approaches.