CVE-2023-31126

Executive Summary

CVE-2023-31126 is a critical stored/reflected cross-site scripting (XSS) vulnerability in the XWiki Commons XML library (org.xwiki.commons:xwiki-commons-xml), specifically in the HTML sanitizer introduced in version 14.6-rc-1. The flaw allows attackers to inject arbitrary HTML code via malformed data attributes that bypass the sanitizer's character filtering, leading to cross-site scripting. The vulnerability affects XWiki instances running versions 14.6-rc-1 through 14.10.3, and is patched in XWiki 14.10.4 and 15.0 RC1. With a CVSS score of 9.1, this represents a critical risk, particularly for public-facing wiki deployments where authenticated or unauthenticated users can submit content processed by the affected sanitizer.

Technical Analysis

The vulnerability resides in the HTML sanitizer component of org.xwiki.commons:xwiki-commons-xml, which is an XML/HTML processing library used by the XWiki platform. The sanitizer was introduced in XWiki version 14.6-rc-1 as part of a hardening effort to filter potentially dangerous HTML content before it is rendered in user pages.

Vulnerability Mechanism

The core flaw is described by the CNA as "Improper Neutralization of Invalid Characters in Data Attribute Names." HTML5 allows custom attributes prefixed with data- (e.g., data-user-id, data-config). The sanitizer's role is to remove dangerous attributes and normalize the rest. However, the validation logic fails to properly reject attribute names that contain invalid characters — specifically data- attribute names that include characters such as / and >.

The attack mechanism operates as follows:

1. The sanitizer receives HTML input containing attributes like data-x/onerror="..." or data-x>onclick="...".
2. Because the sanitizer's attribute name validation only checks for the data- prefix and does not enforce a strict whitelist of allowed characters, malformed names pass through the filtering layer.
3. When the browser later parses this "cleaned" HTML, it interprets the malformed attribute name differently than the server-side sanitizer did. The browser sees data-x/onerror="..." as two distinct attributes (data-x/onerror and onerror), or in the case of > characters, as a premature attribute-name terminator that re-opens the tag context.
4. This parser differential allows event handler attributes like onerror, onclick, onload, or arbitrary tag injection to survive the sanitization process and execute in the victim's browser.

Critically, the NVD description notes that this does NOT affect "restricted cleaning" in HTMLCleaner, where attribute names are aggressively cleaned — characters like / and > are stripped from all attribute names. The vulnerability is specific to the standard sanitization path.

Attack Surface

The attack surface includes any XWiki page or feature that:

• Accepts user-generated HTML content (wiki pages, comments, annotations)
• Uses the HTML sanitizer to filter content before rendering (e.g., display of user-submitted data in a wiki page)
• Is accessible to users with editor permissions, or in some configurations, to unauthenticated users where public pages can be created or where content from other sources is embedded

The vulnerability is server-side — the sanitization happens on the server before rendering, meaning the injected payload becomes persistent (stored XSS) when saved to a wiki page.

Patch Analysis

The NVD description states the problem was patched "by making sure that data attributes only contain allowed characters." This implies the fix enforces a strict character whitelist for attribute names (e.g., alphanumeric characters, hyphens, underscores — per the HTML5 spec for custom data attributes). The fix was released in XWiki 14.10.4 and 15.0 RC1.

Exploitation Scenarios

No public PoC is available; attack chain is inferred from vulnerability class and NVD description. The following exploitation scenarios are based strictly on the described flaw mechanism.

Scenario 1: Stored XSS via Wiki Page Content

Step 1 — Reconnaissance & Target Identification: An attacker identifies a public-facing XWiki deployment running a vulnerable version (14.6-rc-1 through 14.10.3). Reconnaissance is straightforward — XWiki installations expose their version in the HTTP response headers (X-XWiki-Version) or via the footer of pages, and Shodan/Fofa can be used to enumerate public instances.

Step 2 — Triggering the Flaw: The attacker navigates to a wiki page with editing capability (if they have legitimate editor credentials, or if the wiki allows public contribution on certain pages). They open the wiki editor's source mode and insert HTML content containing a malformed data attribute, for example: <img src=x data-foo/onerror="alert(document.cookie)">. The payload's data-foo/onerror attribute name contains a / character that should be rejected by the sanitizer but is not.

Step 3 — Payload Execution: The page is saved. The sanitizer processes the content server-side but fails to neutralize the invalid attribute name. When a victim views the page, the browser parses the HTML. The malformed attribute name is split by the browser into two attributes — data-foo/onerror (ignored as a custom attribute) and onerror (a valid event handler). The onerror handler fires when the image fails to load (the src=x is a broken URL), executing the injected JavaScript in the victim's session.

Step 4 — Post-Exploitation Impact: The injected script executes in the context of the victim's XWiki session. This allows: session hijacking via cookie theft, performing privileged actions (user impersonation, privilege escalation) if the victim is an administrator, page defacement, data exfiltration of wiki content, and lateral movement via internal network requests from the victim's browser.

Scenario 2: Reflected XSS in Query Content

If any XWiki feature reflects user-supplied input through the sanitizer without it being stored (e.g., preview functionality, search result summarization passing through the sanitizer), a crafted link with a malicious query parameter could deliver the payload to a victim without requiring editing rights. However, given the NVD description focuses on stored content, this scenario is speculative but plausible.

Exploitability Assessment

The task suggests CVSS vector of AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — though the exact subscore breakdown was not present in the source data. Based on knowledge of XWiki's architecture, the vulnerability can be triggered with an authenticated low-privilege editor account, and if the wiki allows anonymous editing, by unauthenticated attackers. The scope change (S:C) reflects that the XSS executes in the browser context, which is separate from the web server's security scope.

Impact Assessment

CVSS Score: 9.1 (Critical) with attendant high confidentiality, integrity, and availability impact potential within the changed scope.

Business Impact

• Confidentiality: Successful exploitation enables attackers to steal session cookies, access private wiki content, and read data accessible to the victim's account. In deployments where XWiki is used as an enterprise knowledge base or intranet, this can expose proprietary information, internal documentation, credentials stored in wiki pages, and project data.
• Integrity: Attackers can modify wiki pages — deface content, inject malicious links (e.g., to phishing pages), or substitute legitimate content with fraudulent instructions. In environments where XWiki serves as a trusted internal documentation source, this can lead to integrity failures of organizational knowledge.
• Availability: While XSS primarily targets confidentiality and integrity, an attacker can use the compromised session to delete pages, lock out other users (by changing their credentials or permissions), or upload malicious attachments that degrade service.
• Trust & Reputation: For organizations running public-facing XWiki deployments, a successful stored XSS attack harms the wiki's reputation as a trusted source and may trigger compliance notifications if user data is exposed.

Affected Systems

• XWiki instances running versions 14.6-rc-1 through 14.10.3
• Any application embedding org.xwiki.commons:xwiki-commons-xml 14.6-rc-1 through 14.10.3 as an HTML sanitizer

Blast Radius

Given that the sanitizer is used across XWiki page rendering (wiki macros, annotations, comments, and user profiles), any content feature that processes HTML through the sanitizer is affected. In a typical XWiki deployment, this effectively means all user-generated HTML content on the platform is a potential attack vector. The lack of a required pre-auth condition (if anonymous editing is enabled) expands the blast radius to unauthenticated internet attackers.

EPSS Note

EPSS score of 0.00818 (53.8th percentile of all CVEs) indicates low current likelihood of exploitation in the wild — but this should not be read as a low-risk indicator; it statistically reflects that exploit activity is either unobserved or recent. The absence from CISA KEV means no known in-the-wild exploitation is confirmed.

Detection Guidance

Sigma Rule

title: XWiki Commons XML Sanitizer Bypass - Malformed Data Attribute
id: 7d3c88b8-94e9-4d5a-a13c-1234abcd5678
status: experimental
description: Detects requests to XWiki endpoints containing malformed data- attributes with invalid characters (/, >) indicative of CVE-2023-31126 exploitation attempts.
author: Valtersit Cyber Threat Intelligence
date: 2024/01/15
tags:
    - attack.t1190
    - attack.initial-access
    - cve.2023.31126
logsource:
    category: webserver
    product: apache
    definition: 'XWiki application logs. Requires web server access logs with full URI and POST body captured.'
detection:
    selection_edit_action:
        cs-method: 'POST'
        cs-uri-query|contains:
            - '/bin/edit/'
            - '/bin/preview/'
    selection_save_action:
        cs-uri-query|contains:
            - 'content='
            - 'xpage='
    selection_malformed_attribute:
        cs-body|contains|all:
            - 'data-'
        cs-body|contains|any:
            - '/onerror'
            - '>onerror'
            - '/onclick'
            - '>onclick'
            - '/onload'
            - '>onload'
            - '/onmouseover'
            - '>onmouseover'
    condition: selection_edit_action and selection_malformed_attribute or (selection_save_action and selection_malformed_attribute)
falsepositives:
    - Legitimate developers embedding custom scripts with unusual data attributes (unlikely)
    - Web application firewalls that modify request bodies
level: high

YARA Rule

rule XWiki_CVE_2023_31126_Malformed_Data_Attribute
{
    meta:
        author = "Valtersit Cyber Threat Intelligence"
        description = "Detects HTML payloads containing malformed data- attributes with embedded event handlers, indicative of CVE-2023-31126 exploit attempts"
        cve = "CVE-2023-31126"
        date = "2024-01-15"
        severity = "critical"
    strings:
        $a1 = /data-[a-z0-9\-]*\/on(error|click|load|mouseover|submit)/ nocase
        $a2 = /data-[a-z0-9\-]*>on(error|click|load|mouseover|submit)/ nocase
        $a3 = /data-[a-z0-9\-]*\/onblur/ nocase
        $a4 = /data-[a-z0-9\-]*>onblur/ nocase
        $b1 = /data-[a-z0-9\-]*\/[a-z]+\s*=/ nocase
        $b2 = /data-[a-z0-9\-]*>\s*[a-z]+\s*=/ nocase
        $c1 = "javascript:" nocase
    condition:
        any of ($a*) or (any of ($b*) and $c1)
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"ET EXPLOIT XWiki CVE-2023-31126 Malformed Data Attribute XSS Attempt"; flow:to_server,established; content:"data-"; nocase; http_client_body; pcre:"/data-[a-zA-Z0-9\-]*[\/>]on(afterprint|beforeprint|beforeunload|blur|change|click|contextmenu|copy|cut|dblclick|error|focus|hashchange|input|keydown|keypress|keyup|load|message|mousedown|mousemove|mouseover|mouseup|offline|online|pagehide|pageshow|paste|popstate|resize|scroll|select|submit|toggle|unload|wheel)\s*=/iU"; sid:100xxxx; rev:1; metadata:created_at 2024_01_15, updated_at 2024_01_15, cve CVE_2023_31126; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2023-31126; classtype:web-application-attack; priority:1)

Elastic Detection

// Assumes application logs are indexed with fields: http.method, url.path, http.request.body.content
sequence by host.name, source.ip with maxspan=30s
  [ network where http.request.method == "POST" and url.path like "*edit*" ]
  [ network where http.request.body.content like "*data-*" and
    (http.request.body.content like "*/onerror" or
     http.request.body.content like "*/onclick" or
     http.request.body.content like "*/onload" or
     http.request.body.content like "*>onerror" or
     http.request.body.content like "*>onclick" or
     http.request.body.content like "*>onload") ]

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=iis OR sourcetype=apache
| where like(_raw, "%data-%")
| regex _raw = "data-[a-zA-Z0-9\-]*(/onerror|/onclick|/onload|>onerror|>onclick|>onload)\s*="
| eval exploit_attempt="CVE-2023-31126"
| table _time, src_ip, host, uri_path, http_method, user_agent, _raw
| sort - _time

Wazuh OSSEC Rule

<group name="xwiki,web_attack,xss,cve_2023_31126,">
  <rule id="100311" level="15">
    <if_sid>31122</if_sid>
    <regex>data-[a-zA-Z0-9\-]*(/onerror|/onclick|/onload|>onerror|>onclick|>onload)</regex>
    <description>CVE-2023-31126 XWiki Commons XML sanitizer bypass: malformed data attribute XSS attempt</description>
    <group>attack.t1190,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence Assessment

Patch status: UNPATCHED (confidence 0/4) — No patch evidence available from any tracked source at the time of this analysis. The NVD description states the fix is included in XWiki 14.10.4 and 15.0 RC1, but no vendor advisory or CVE patch link is confirmed from our tracked sources.

1. Immediate Mitigations (Layered Approach)

• Upgrade priority: If your XWiki instance runs version 14.6-rc-1 through 14.10.3, upgrade to 14.10.4 (recommended LTS) or 15.0 RC1+ immediately. This is the ONLY effective mitigation — no workarounds exist per the NVD description.
• Temporary access controls: If immediate upgrade is impossible:
  • Disable anonymous editing on the wiki (Administration → Users & Rights → Global Rights) to restrict the attack surface to authenticated users only.
  • Restrict page creation/edit rights to trusted users.
  • Temporarily disable the HTML sanitizer-dependent rendering features (e.g., HTML macros that bypass the sanitizer for privileged users should be disabled entirely).
  • Review and revoke any user with "edit" rights on wiki pages that have been edited publicly.
• WAF rule deployment: Deploy virtual patching via WAF rules that block requests containing data- attribute patterns with / or > characters followed by common event handler names (onerror, onclick, onload, etc.).
• Content Security Policy (CSP): Implement a strict CSP header that disables inline script execution (script-src 'self'), which would block most XSS payloads from executing even if the sanitizer is bypassed. Note: CSP is a defense-in-depth control and does not fully protect against captured-XSS vectors.

2. Patch/Upgrade Steps

1. Verify your XWiki version: Check the footer of the wiki page or navigate to /bin/view/Main/ and look for version info. Alternatively, run curl -I https://your-wiki.example.com and inspect the X-XWiki-Version header.
2. If vulnerable (14.6-rc-1 through 14.10.3):
   • Download XWiki 14.10.4 from the official XWiki download page (https://www.xwiki.org/xwiki/bin/view/Download/).
   • Follow the standard upgrade procedure: backup database and webapp, replace the webapps/xwiki directory and the xwiki-commons-xml JAR files, restart the application server.
   • For Debian/RPM-based installations, use the package manager upgrade.
3. Verify the upgrade: Confirm version in the page footer or via the version header, and run the XWiki distribution wizard if prompted.
4. After upgrade, re-audit existing wiki pages for injected XSS payloads — perform a full content export/scan for patterns matching malformed data attributes.

3. Long-Term Hardening

• Strict Input Validation: Configure XWiki's HTML sanitizer to restrict cleaning requirements. If available in the version you run, enable "restricted cleaning" in HTMLCleaner settings, which strips characters like / and > from all attribute names.
• Regular Upgrade Cadence: Establish a policy for applying XWiki updates within 30 days of release, particularly for security-relevant releases.
• Monitor Security Advisories: Subscribe to XWiki security announcements (https://www.xwiki.org/xwiki/bin/view/Main/Security/) and the XWiki Announcements mailing list.
• Web Application Firewall (WAF): Deploy a WAF (e.g., ModSecurity with OWASP CRS) configured for the OWASP XSS ruleset in front of the XWiki instance.
• Audit User Permissions: Periodically review wiki permissions; minimize the number of users with edit rights, and remove any anonymous write access unless strictly required by business function.
• Logging & Monitoring: Ensure web server access logs capture full POST bodies (where privacy constraints permit) and are integrated into the SIEM for continuous monitoring using the detection rules above.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-31126 — Official NVD record with description and reference links.
2. XWiki Security Advisory: https://www.xwiki.org/xwiki/bin/view/Main/Security/ — XWiki's official security page. The specific advisory for this CVE should be listed here (search for "CVE-2023-31126").
3. XWiki Commons XML Project Page: https://github.com/xwiki/xwiki-commons — Source repository for xwiki-commons-xml. Review of the xml module's sanitizer code and git history for the patched commit.
4. XWiki Release Notes — 14.10.4: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki14104/ — Official release notes confirming the security fix.

Threat Actor Campaigns / In-the-Wild Evidence

No known threat actor campaigns or exploit-in-the-wild evidence is available for CVE-2023-31126 at the time of this report. The CVE is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score of 0.00818 suggests low observed exploitation activity, but given the critical CVSS score and the ease of exploitation (low complexity, network attack vector), organizations should treat this as a high-priority patch target regardless of current exploit evidence.