Xwiki CVE-2025-49581

This vulnerability presents exceptionally high real-world risk across multiple dimensions: (1) CVSS 8.8 with AV:N (network-accessible), AC:L (low complexity), PR:L (low privilege requirement—only edit rights needed), indicates broad attack surface; (2) the privilege requirement is particularly dangerous because edit rights are commonly delegated to users in collaborative wiki environments; (3) the impact is complete—confidentiality, integrity, and availability all rated High (C:H/I:H/A:H), enabling full system compromise including data exfiltration, malware installation, and denial of service; (4) no user interaction required (UI:N) means automated exploitation is feasible; (5) CWE-94 (code generation) is a fundamental class frequently exploited in real-world attacks; (6) the vulnerability affects multiple active release branches (16.4.x, 16.10.x, 17.0.x), indicating broad deployment exposure; (7) patches are available but require immediate deployment given the low barrier to exploitation (any page editor can trigger). EPSS probability would likely exceed 85-90% given the low attack complexity and privilege requirements. This is not a theoretical high-CVSS issue—it is a genuine, immediately exploitable privilege escalation affecting widely deployed collaborative platforms.

A semi-trusted user (e.g., project team member with page edit rights) creates a custom wiki macro named 'GetAdminStatus' with a parameter 'query' that accepts wiki syntax. The attacker sets the parameter's default value to contain a Groovy script: {{groovy}}java.lang.Runtime.getRuntime().exec('whoami'){{/groovy}}. The attacker then edits a high-privilege system page (e.g., XWiki.ChildrenMacro or another page in the XWiki namespace with programming rights) to reference this macro using its default parameter. When the page is viewed or rendered by an administrator or during system processing, the macro is invoked, the default parameter containing the Groovy script is evaluated with the page's programming rights, and the attacker's arbitrary code executes in the XWiki Java VM context. This grants the attacker full access to the database, file system, and XWiki configuration. No user interaction or special conditions are required beyond the attacker having basic edit rights. Attack complexity is low; exploitation is deterministic and automatable. Proof-of-concept code would involve: (1) REST API call to create a malicious macro page, (2) REST API call to modify a high-privilege system page to invoke it, (3) trigger page rendering to execute the payload.