A significant vulnerability has been discovered in the widely-used Tracking Code Manager WordPress plugin, identified as CVE-2024-6335. With over 100,000 installations, this plugin has become a valuable tool for managing tracking scripts, but a serious security flaw allows attackers to exploit a Stored Cross-Site Scripting (XSS) vulnerability. This flaw enables attackers to embed malicious JavaScript (JS) code within the plugin, leading to account takeovers and potential backdoor creation. Improper sanitization of inputs is the primary cause of this vulnerability, putting numerous WordPress sites at risk of exploitation.
| CVE | CVE-2024-6335 |
| Plugin | Tracking Code Manager < 2.3.0 |
| Critical | High |
| All Time | 2 706 000 |
| Active installations | 100 000+ |
| Publicly Published | August 19, 2024 |
| Last Updated | August 19, 2024 |
| Researcher | Dmitrii Ignatyev |
| OWASP TOP-10 | A7: Cross-Site Scripting (XSS) |
| PoC | Yes |
| Exploit | No |
| Reference | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6335 https://wpscan.com/vulnerability/3bfb6b3f-8642-4807-b6b3-f214b26e96c2/ |
| Plugin Security Certification by CleanTalk |  |
| Logo of the plugin |  |
Timeline
| June 3, 2024 | Plugin testing and vulnerability detection in the Tracking Code Manager have been completed |
| June 3, 2024 | I contacted the author of the plugin and provided a vulnerability PoC with a description and recommendations for fixing |
| August 19, 2024 | Registered CVE-2024-6335 |
Discovery of the Vulnerability
The CVE-2024-6335 vulnerability was uncovered during a thorough security assessment. It was found that the Tracking Code Manager plugin allowed the injection of untrusted JavaScript code through the “code” field in the plugin’s settings. The problem lies in the plugin’s lack of sufficient input validation, which permits malicious payloads to be saved and executed when an admin or editor interacts with the plugin. A proof-of-concept (PoC) demonstrated that by modifying the “code” field with a script like <img src=x onerror=alert(1)>, an attacker could execute arbitrary JavaScript, which could then lead to full site control or backdoor creation, especially when executed in the context of an admin account.
Understanding of Stored XSS attack’s
Cross-Site Scripting (XSS) vulnerabilities have long been a common security concern for WordPress, particularly when input fields are not properly sanitized. XSS allows attackers to inject scripts into trusted websites, which then execute in the browsers of users who visit or interact with the site. In this case, the vulnerability in Tracking Code Manager follows the same pattern. Editors or admins with permission to add tracking scripts are allowed to insert JavaScript without proper filtering, making the system vulnerable to stored XSS. This vulnerability becomes particularly dangerous because of the elevated privileges of the roles involved, which can lead to severe consequences such as data theft, user session hijacking, or backdoor creation.
Real-world examples of XSS attacks in WordPress often involve attackers injecting malicious code into comment sections, widgets, or input fields in plugins. In this scenario, the unfiltered JavaScript in Tracking Code Manager could be used to hijack admin sessions, gain unauthorized access, or steal sensitive information. These exploits often open the door for more serious attacks, including website defacement, redirecting users to phishing sites, or using the compromised site to distribute malware.
Exploiting the Stored XSS Vulnerability
The exploitation of CVE-2024-6335 requires minimal effort for attackers with editor or admin privileges. An attacker can simply create a new tracking code entry within the Tracking Code Manager, injecting their malicious JavaScript into the “code” field. Once the changes are saved, the script is stored within the WordPress environment. Whenever an admin or editor reviews or interacts with the plugin’s settings, the JavaScript is executed, allowing the attacker to execute arbitrary code. In testing, a simple payload like <img src=x onerror=alert(1)> was used to demonstrate the vulnerability. However, a more complex payload could be designed to steal cookies, gain administrator credentials, or install a persistent backdoor within the WordPress environment. The attacker could even use this XSS to create additional administrator accounts, escalating the attack’s impact.
POC:
You should create new Track Code. Change "code" field to "Malicious JS code eval() and etc. For example <img src=x onerror=alert(1)>" -> Save Settings (Admins and editors are allowed to use JS in posts/pages/comments/etc, so the unfiltered_html capability should be disallowed when testing for Stored XSS using such roles)____
The risks associated with CVE-2024-6335 are vast, particularly because the Tracking Code Manager plugin is used on over 100,000 WordPress sites. An attacker exploiting this vulnerability could gain administrative control over a site, implant backdoors, and potentially steal sensitive information. For instance, compromised websites could be used to distribute malicious scripts or redirect users to phishing sites. The combination of Stored XSS and the plugin’s widespread use creates an attractive target for cybercriminals looking to compromise multiple WordPress sites at once. Moreover, the ability to create persistent backdoors means that attackers could retain control over the site long after the initial breach, making detection and mitigation more difficult.
Recommendations for Improved Security
To address the risks posed by vulnerabilities like CVE-2024-6335, several security measures should be implemented. First and foremost, WordPress administrators should ensure that all plugins are kept up-to-date, as developers frequently release patches to resolve such vulnerabilities. Plugin developers, on the other hand, need to implement rigorous input validation and sanitization processes, ensuring that all user-supplied data is filtered before execution. In this specific case, disallowing unfiltered HTML or JavaScript for editor-level users can significantly reduce the risk of XSS attacks. Additionally, a web application firewall (WAF) can provide an extra layer of protection by detecting and blocking malicious requests before they reach the WordPress environment. For admins, reviewing and restricting user roles and permissions is also a crucial step in minimizing the attack surface, especially for plugins that allow script injection.
By taking proactive measures to address Stored XSS vulnerabilities like CVE-2024-6158, WordPress website owners can enhance their security posture and safeguard against potential exploitation. Stay vigilant, stay secure.
#WordPressSecurity #StoredXSS #WebsiteSafety #StayProtected #VeryHighVulnerability
Use CleanTalk solutions to improve the security of your website
ARTYOM K.
