CVE-2026-24128: 
Java vulnerability analysis and mitigation

CVE-2026-24128 is a reflected Cross-Site Scripting (XSS) vulnerability in XWiki Platform affecting the templates/logging_macros.vm template file. It allows an unauthenticated attacker to craft a malicious URL that, when visited by a victim, executes arbitrary actions within XWiki using the victim's privileges. Affected versions span from 7.0-milestone-2 through 16.10.11, 17.0.0-rc-1 through 17.4.4, and 17.5.0-rc-1 through 17.7.0. The vulnerability was disclosed on January 23, 2026, and carries a CVSS v3.1 base score of 6.1 (Medium) and a CVSS v4.0 base score of 6.5 (Medium) (GitHub Advisory).

The root cause is improper neutralization of script-related HTML tags in a web page (CWE-79/CWE-80). Specifically, the logging_macros.vm template failed to escape extension IDs before rendering them in log messages — the vulnerable line used $argument directly instead of $!escapetool.xml($argument), allowing attacker-controlled input to be reflected as unescaped HTML (GitHub Commit). An attacker can exploit this by crafting a URL that triggers an extension-related log message containing a malicious payload (e.g., an extension ID containing <script> tags), which is then rendered in the victim's browser. No authentication or special privileges are required on the attacker's side; only passive user interaction (the victim visiting the crafted URL) is needed (GitHub Advisory).

Successful exploitation allows an attacker to execute arbitrary JavaScript in the context of the victim's browser session within the XWiki installation. If the victim holds administrative or programming rights, the attacker can leverage those privileges to gain full control of the XWiki installation, including data exfiltration, unauthorized configuration changes, content modification, and potential further compromise of the underlying system. The CVSS v4.0 subsequent system impact metrics rate confidentiality, integrity, and availability as High, reflecting the potential for complete installation takeover when a privileged user is targeted (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of disclosure (GitHub Advisory). The EPSS score is approximately 0.015% (0.000150), indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Notably, a Nuclei detection template was submitted to the ProjectDiscovery nuclei-templates repository, indicating community interest in automated scanning for this vulnerability (Nuclei Templates PR).

1. Reconnaissance: Identify publicly accessible XWiki instances running affected versions (7.0-milestone-2 through 16.10.11, 17.0.0-rc-1 through 17.4.4, or 17.5.0-rc-1 through 17.7.0) using tools like Shodan or Censys, or by checking the XWiki version page.
2. Identify vulnerable endpoint: Locate a page or action in XWiki that triggers extension-related log messages rendered via logging_macros.vm, such as the distribution wizard or extension installation pages.
3. Craft malicious URL: Construct a URL that passes a malicious extension ID containing an XSS payload (e.g., <script>alert(document.cookie)</script> or a more sophisticated payload) as a URL parameter (e.g., extensionId) to the vulnerable endpoint.
4. Deliver to victim: Send the crafted URL to a target user — ideally one with administrative or programming rights — via phishing, social engineering, or embedding in content.
5. Payload execution: When the victim visits the URL, XWiki renders the unescaped extension ID in the log message output, causing the injected script to execute in the victim's browser session.
6. Privilege abuse: Use the victim's session token or execute XWiki API calls (e.g., creating admin accounts, modifying wiki content, or installing malicious extensions) with the victim's privileges to achieve full installation compromise (GitHub Advisory, GitHub Commit).

• Network: Unusual HTTP requests to XWiki distribution or extension management endpoints (e.g., /xwiki/bin/view/XWiki/Distribution) with URL parameters containing HTML/JavaScript special characters (<, >, script, onerror, etc.); outbound requests from the XWiki server to unknown external hosts following such requests.
• Logs: XWiki access logs showing GET/POST requests to extension-related pages with encoded or raw XSS payloads in extensionId, extensionVersion, or similar parameters; error log entries in XWiki logs referencing malformed extension IDs.
• File System: Unexpected new wiki pages, scripts, or user accounts created shortly after suspicious log entries; modifications to XWiki configuration files or installed extensions.
• Process/Behavior: Unexpected administrative actions (new admin user creation, extension installation, configuration changes) performed by a privileged user account that may indicate session hijacking following XSS exploitation.

XWiki has released patched versions addressing this vulnerability: 16.10.12 (for the 16.x branch), 17.4.5 (for the 17.0–17.4 branch), and 17.8.0-rc-1 (for the 17.5+ branch) (GitHub Release 16.10.12, GitHub Release 17.4.5). For installations that cannot be upgraded immediately, a manual workaround is available: in templates/logging_macros.vm, change line 116 from #set ($_extensionName = $argument) to #set ($_extensionName = $!escapetool.xml($argument)) — no server restart is required (GitHub Commit). Additionally, restricting access to administrative interfaces and training users to be cautious of unsolicited URLs can reduce risk.

The vulnerability was discovered and reported by Mike Cole (@mikecole-mg), who was credited in the official GitHub Security Advisory (GitHub Advisory). A community blog post titled "CVE-2026-24128: Log, Stock and Barrel — XSS in XWiki's Logging Macros" was published on dev.to shortly after disclosure, indicating moderate community interest. The ProjectDiscovery community submitted a Nuclei detection template for automated scanning, reflecting practitioner interest in detection tooling (Nuclei Templates PR). Red Hat also tracked the vulnerability in their CVE database (Red Hat CVE).