CVE-2026-38472 in GazellePW
Summary
by MITRE • 08/26/2026
A Stored XSS vulnerability in forum reward comments in GazellePW (GazellePosterWall) commit 86c4bedf727691b5a97af42a4864869d18446449 allows remote attackers to inject arbitrary JavaScript via the c parameter in /forums.php?action=ajax_get_jf which is later rendered in the data-tooltip attribute in /forums.php?action=viewthread and interpreted as HTML by the Tooltipster configuration.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified involves a Stored Cross-Site Scripting (XSS) flaw within the GazellePW application, specifically affecting the forum reward comment functionality. This security issue stems from insufficient input validation and sanitization mechanisms when processing user-supplied data in the AJAX endpoint responsible for retrieving forum comments. The attack vector targets the c parameter sent to /forums.php?action=ajax_get_jf. When an attacker submits a malicious payload through this interface, the application stores the unsanitized JavaScript code directly into its database without applying adequate encoding or filtering rules. This lack of proper data handling allows the injected script to persist on the server side rather than being executed immediately in the context of the request that created it.
The operational impact manifests when other users interact with the affected forum thread. The stored malicious payload is retrieved and rendered within the data-tooltip attribute of an HTML element associated with a specific comment or reward entry. Crucially, the application utilizes Tooltipster, a jQuery tooltip plugin, to display this content. Unlike standard text rendering which would escape special characters, Tooltipster interprets the contents of the data-tooltip attribute as HTML by default configuration settings. This behavior creates a direct execution path for arbitrary JavaScript code within the victim's browser session. The attacker can thus execute scripts in the context of the vulnerable application domain, bypassing same-origin policy restrictions that typically limit cross-site attacks.
From a technical perspective, this vulnerability represents a classic case of improper neutralization of input during web page generation. It aligns with CWE-79, which defines Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting. The specific mechanism here involves the storage phase where data is accepted without validation and the rendering phase where trusted content sources are treated as executable code due to framework configuration choices. This dual failure allows a remote attacker to inject client-side scripts that run whenever a legitimate user views the compromised thread. Such execution can lead to session hijacking, credential theft via keyloggers or form grabs, defacement of the forum interface, or redirection to malicious phishing sites designed to harvest sensitive information from unsuspecting users.
The severity of this vulnerability is compounded by its stored nature and the specific rendering context provided by Tooltipster. Because the payload persists in the database, every user who visits the affected page becomes a potential victim without requiring any additional interaction beyond viewing the thread. This contrasts with reflected XSS where the attacker must trick each individual into clicking a malicious link. The use of data attributes for tooltip content is common but often misunderstood regarding security implications; developers frequently assume that because the value comes from an attribute, it will be treated as plain text by the browser DOM parser. However, when JavaScript libraries like Tooltipster explicitly parse these values as HTML to support rich formatting, they inadvertently create a vector for script execution if input sanitization is absent.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. The primary fix involves implementing strict output encoding or context-aware escaping on the c parameter before it is stored in the database or rendered into the HTML structure. Specifically, when inserting data into a tooltip attribute that will be interpreted as HTML by a JavaScript library, developers should ensure that all special characters are encoded to their corresponding HTML entities. Alternatively, if Tooltipster supports plain text mode for tooltips, enabling this feature would prevent the interpretation of injected scripts as executable code. Input validation should also be enforced at the entry point in /forums.php?action=ajax_get_jf to reject or sanitize any content containing script tags, event handlers, or other dangerous HTML constructs before persistence occurs.
Furthermore, adopting a Content Security Policy (CSP) can provide an additional layer of defense by restricting the sources from which scripts are allowed to execute. While CSP does not prevent the initial injection, it can mitigate the impact by blocking the execution of inline scripts and limiting connections to unauthorized domains. This reduces the effectiveness of attacks such as data exfiltration or loading external malicious resources. Regular security audits and code reviews focusing on how third-party libraries handle user-supplied data are essential for preventing similar vulnerabilities in other parts of the application. Developers should also consider using modern frameworks that automatically escape output by default, reducing the risk of manual errors in HTML generation logic.
In terms of classification within industry standards, this vulnerability falls under CWE-79 and maps to ATT&CK technique T1059, specifically sub-technique 007 for JavaScript execution. The attack chain involves initial access through a web application interface followed by code injection that leads to potential credential theft or further compromise depending on the privileges of the targeted user accounts. Organizations running GazellePW should prioritize patching this issue given its ability to affect multiple users passively and its direct impact on session integrity. Ensuring that all dynamic content rendered via JavaScript libraries is properly sanitized remains a critical requirement for maintaining web application security posture against persistent client-side attacks.