CVE-2026-24128: XWiki Platform Reflected XSS Vulnerability

CVE-2026-24128 Overview

CVE-2026-24128 is a reflected Cross-Site Scripting (XSS) vulnerability affecting XWiki Platform, a generic wiki platform offering runtime services for applications built on top of it. This vulnerability allows an attacker to craft a malicious URL that, when visited by a victim, executes arbitrary JavaScript code within the context of the victim's authenticated session. The impact is particularly severe when the victim possesses administrative or programming rights, as an attacker can exploit those privileges to gain full access to the XWiki installation.

Critical Impact

Attackers can execute arbitrary actions with the same privileges as the victim. If an administrator is targeted, this can result in complete compromise of the XWiki installation, including unauthorized data access, modification, or full system takeover.

Affected Products

• XWiki Platform versions 7.0-milestone-2 through 16.10.11
• XWiki Platform versions 17.0.0-rc-1 through 17.4.4
• XWiki Platform versions 17.5.0-rc-1 through 17.7.0

Discovery Timeline

• 2026-01-24 - CVE-2026-24128 published to NVD
• 2026-01-26 - Last updated in NVD database

Technical Details for CVE-2026-24128

Vulnerability Analysis

This reflected XSS vulnerability exists in the logging macros template (templates/logging_macros.vm) of XWiki Platform. The vulnerability stems from improper handling of extension ID arguments when rendering log messages. When extension information is displayed, the extension name is incorporated into HTML output without proper sanitization, allowing an attacker to inject malicious script content.

The vulnerability is network-exploitable and requires no authentication to trigger, though user interaction is necessary as the victim must click a malicious link. When exploited against users with elevated privileges, the attacker can perform actions with administrative or programming rights, potentially leading to complete compromise of the XWiki installation.

Root Cause

The root cause is a missing XML/HTML escape function when setting the $_extensionName variable in the Velocity template. The original code directly assigned the $argument value to $_extensionName without sanitization, which was then embedded into an HTML anchor tag. This allowed attackers to inject arbitrary HTML and JavaScript by manipulating the extension argument parameter.

Attack Vector

The attack vector is network-based, requiring an attacker to craft a specially designed URL containing malicious JavaScript payload in the extension ID parameter. When a victim clicks this link while authenticated to the XWiki instance, the malicious script executes in the context of their session. The attacker can then:

1. Steal session cookies or authentication tokens
2. Perform actions on behalf of the victim user
3. If the victim has admin rights, install malicious extensions or modify system configurations
4. Extract sensitive data from the wiki

// Security patch in logging_macros.vm
             #set ($version = $argument.versionConstraint)
           #end
           #set ($_extensionURL = "#getExtensionURL($argument.id, $version)")
-          #set ($_extensionName = $argument)
+          #set ($_extensionName = $!escapetool.xml($argument))
         #end
         #set ($message = "$message<a href=""$_extensionURL"" class=""extension-link"">$_extensionName</a>")
       #elseif ($argument.listIterator())

Source: GitHub Commit Update

Detection Methods for CVE-2026-24128

Indicators of Compromise

• Suspicious URLs containing encoded JavaScript or HTML tags in extension-related parameters
• Web server logs showing requests with unusual characters in extension ID or name parameters
• Unexpected administrative actions or configuration changes that legitimate users did not perform
• User reports of suspicious behavior after clicking links to the XWiki instance

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block requests containing common XSS payloads in URL parameters
• Monitor application logs for requests containing script tags, event handlers, or JavaScript protocol handlers in extension-related parameters
• Deploy browser-based XSS detection mechanisms and Content Security Policy (CSP) headers to mitigate successful exploitation
• Conduct regular security scanning of XWiki instances to identify unpatched versions

Monitoring Recommendations

• Enable detailed access logging for the XWiki application to capture full request URLs and parameters
• Configure alerting for requests that match XSS payload patterns targeting the logging functionality
• Monitor for unusual session activity following visits from external referrers
• Implement user behavior analytics to detect privilege abuse following potential XSS exploitation

How to Mitigate CVE-2026-24128

Immediate Actions Required

• Upgrade XWiki Platform to a patched version immediately: 17.8.0-rc-1, 17.4.5, or 16.10.12
• If immediate upgrade is not possible, apply the manual patch to templates/logging_macros.vm
• Review recent access logs for potential exploitation attempts
• Implement Content Security Policy (CSP) headers as an additional defense layer

Patch Information

XWiki has released patched versions that address this vulnerability. The fix involves adding proper XML escaping to the extension name argument before it is rendered in HTML output. Official patched versions are available:

• XWiki Platform 16.10.12 for the 16.x branch
• XWiki Platform 17.4.5 for the 17.4.x branch
• XWiki Platform 17.8.0-rc-1 for the latest development branch

For detailed vulnerability information, refer to the GitHub Security Advisory GHSA-wvqx-m5px-6cmp and Jira Issue XWIKI-23462.

Workarounds

• Apply the single-line patch manually to templates/logging_macros.vm by changing #set ($_extensionName = $argument) to #set ($_extensionName = $!escapetool.xml($argument))
• No server restart is required after applying the manual patch
• Implement strict Content Security Policy (CSP) headers to prevent inline script execution as a defense-in-depth measure
• Consider restricting access to administrative functions until the patch can be applied

# Manual patch verification
# Navigate to XWiki installation directory and check the file:
grep -n "escapetool.xml" templates/logging_macros.vm

# If the patch is applied correctly, you should see the escaped version:
# #set ($_extensionName = $!escapetool.xml($argument))