XWiki Rendering CVE-2025-66474

Requires an authenticated account with edit rights over at least one document - critically, the ability to edit one's own user profile suffices, so on any XWiki instance permitting self-registration or granting normal users profile-edit rights, this is reachable by ordinary/low-trust users (PR:L). The vulnerable behavior triggers when a wiki-syntax field's rendered output is embedded in an HTML macro; the attacker closes the macro via {{/html}} variants (including forms with spaces after the macro name) and injects script macros. No user interaction by a victim and no non-default configuration is required beyond having script/programming-rights macros processable in the standard rendering pipeline. Affected: xwiki-rendering-xml <16.10.10, >=17.0.0-rc-1 <17.4.3, and >=17.5.0-rc-1 <17.6.0-rc-1; no workaround exists other than upgrading.

This is a genuinely high-priority issue, not merely a high-CVSS paper tiger. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) plus full VC:H/VI:H/VA:H indicates a remotely reachable, low-complexity flaw requiring only a low-privilege authenticated account - and the GHSA confirms that privilege bar is extremely low: any user who can edit their own profile qualifies, which on most XWiki instances includes any self-registered/regular user. CWE-95 (eval injection) combined with the ability to run Groovy/Python script macros with programming rights means the impact is full RCE and unrestricted read/write across the wiki. Publicly available exploit code exists (the GHSA supplies a concrete payload {{html}}{{/html {{/html}}}} and the JIRA tickets are referenced as exploit sources), which sharply raises real-world risk even though there is no CISA KEV listing and no confirmed active exploitation. EPSS is moderate at 1.02% (62nd percentile) - elevated but not extreme - consistent with a public PoC that is not yet part of automated mass-exploitation. The main gating factor is authentication (PR:L), so the practical risk is highest for instances that permit open registration or have many low-trust users. Signals are consistent across sources: vendor GHSA, NVD, source-code diffs, and PoC all agree on mechanism and impact.

A low-privileged but authenticated XWiki user edits a wiki-syntax field they control (e.g., the 'About' field of their own profile) and inserts a payload such as {{html}}{{/html {{/html}}}} that escapes the wrapping HTML macro. Because rendering output is embedded in an HTML macro with insufficient escaping of the closing {{/html}} token (especially variants with spaces after the macro name), the attacker can then inject script macros (Groovy/Python) that execute with programming rights, achieving RCE and full read/write access to wiki content. A public PoC and detailed advisory exist, making reproduction straightforward.