#jira

Miami, Florida, 18th June 2025, CyberNewsWire

### Impact When an attacker without script or programming right creates an XClass definition in XWiki (requires edit right), and that same document is later edited by a user with script, admin, or programming right, malicious code could be executed with the rights of the editing user without prior warning. In particular, this concerns custom display code, the script of computed properties and queries in database list properties. Note that warnings before editing documents with dangerous properties have only been introduced in XWiki 15.9, before that version, this was a known issue and the advice was simply to be careful. ### Patches This has been patched in XWiki 16.10.2, 16.4.7 and 15.10.16 by adding an analysis for the respective XClass properties. ### Workarounds We're not aware of any real workarounds apart from just being careful with editing documents previously edited by untrusted users as a user with script, admin or programming right.

### Impact Any XWiki user with edit right on at least one App Within Minutes application (the default for all users XWiki) can obtain programming right/perform remote code execution by editing the application. The detailed reproduction steps can be found in the [original bug report](https://jira.xwiki.org/browse/XWIKI-22719). ### Patches This vulnerability has been fixed in XWiki 17.0.0, 16.4.7, and 16.10.3. ### Workarounds Restricting edit rights on all existing App Within Minutes applications to trusted users mitigates at least the PoC exploit, but we can't exclude that there are other ways to exploit this vulnerability.

### Impact When a user without script right creates a document with an `XWiki.Notifications.Code.NotificationDisplayerClass` object, and later an admin edits and saves that document, the possibly malicious content of that object is output as raw HTML, allowing XSS attacks. While the notification displayer executes Velocity, the existing generic analyzer already warns admins before editing Velocity code. Note that warnings before editing documents with dangerous properties have only been introduced in XWiki 15.9, before that version, this was a known issue and the advice was simply to be careful. ### Patches This vulnerability has been patched in XWiki 15.10.16, 16.4.7, and 16.10.2 by adding a required rights analyzer that warns the admin before editing about the possibly malicious code. ### Workarounds We're not aware of any real workarounds apart from just being careful with editing documents previously edited by untrusted users as a user with script, admin or programming right.

### Impact The title of every single page whose reference is known can be accessed through the REST API as long as an XClass with a page property is accessible, this is the default for an XWiki installation. This allows an attacker to get titles of pages whose reference is known, one title per request. This doesn't affect fully [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki) as the REST endpoint checks access rights on the XClass definition. The impact on confidentiality depends on the strategy for page names. By default, page names match the title, so the impact should be low but if page names are intentionally obfuscated because the titles are sensitive, the impact could be high. ### Patches This has been fixed in XWiki 16.4.7, 16.10.3 and 17.0.0 by adding access control checks before getting the title of any page. ### Workarounds We're not aware of any workarounds.

### Impact When a user without script right creates a document with an `XWiki.Notifications.Code.NotificationEmailRendererClass` object, and later an admin edits and saves that document, the email templates in this object will be used for notifications. No malicious code can be executed, though, as while these templates allow Velocity code, the existing generic analyzer already warns admins before editing Velocity code. The main impact would thus be to send spam, e.g., with phishing links to other users or to hide notifications about other attacks. Note that warnings before editing documents with dangerous properties have only been introduced in XWiki 15.9, before that version, this was a known issue and the advice was simply to be careful. ### Patches This has been patched in XWiki 16.10.2, 16.4.7 and 15.10.16 by adding an analysis for the respective XClass properties. ### Workarounds We're not aware of any real workarounds apart from just being careful with editing documents previo...

### Impact Any user with edit right on a page (could be the user's profile) can execute code (Groovy, Python, Velocity) with programming right by defining a wiki macro. This allows full access to the whole XWiki installation and thus impacts its confidentiality, integrity and availability. The main problem is that if a wiki macro parameter allows wiki syntax, its default value is executed with the rights of the author of the document where it is used. This can be exploited by overriding a macro like the `children` macro that is used in a page that has programming right like the page `XWiki.ChildrenMacro` and thus allows arbitrary script macros. The full reproduction steps can be found in the [original issue](https://jira.xwiki.org/browse/XWIKI-22760). ### Patches This vulnerability has been patched in XWiki 16.4.7, 16.10.3 and 17.0.0 by executing wiki parameters with the rights of the wiki macro's author when the parameter's value is the default value. ### Workarounds We're not aware...

### Impact When editing content that contains "dangerous" macros like malicious script macros that were authored by a user with fewer rights, XWiki warns about the execution of these macros since XWiki 15.9RC1. These required rights analyzers that trigger these warnings are incomplete, allowing an attacker to hide malicious content. For most macros, the existing analyzers don't consider non-lowercase parameters. Further, most macro parameters that can contain XWiki syntax like titles of information boxes weren't analyzed at all. Similarly, the "source" parameters of the content and context macro weren't anylzed even though they could contain arbitrary XWiki syntax. In the worst case, this could allow a malicious to add malicious script macros including Groovy or Python macros to a page that are then executed after another user with programming righs edits the page, thus allowing remote code execution. ### Patches The required rights analyzers have been made more robust and extended to...

### Impact Pages can gain script or programming rights when they contain a link and the target of the link is renamed or moved. This might lead to execution of scripts contained in xobjects that should have never been executed. This vulnerability affects all version of XWiki since 8.2 and 7.4.5. ### Patches The patch consists in only setting the `originalMetadataAuthor` when performing such change, so that it's displayed in the history but it has no impact on the right evaluation (i.e. the original author of the changes is still used for right computation). This patch has been applied on XWiki 16.4.7, 17.1.0RC1, 16.10.4. ### Workarounds There's no workaround for this vulnerability, except preventing to perform any refactoring operation with users having more than edit rights. Administrators are strongly advised to upgrade. If not possible, the patch only impacts module `xwiki-platform-refactoring-default` so it's possible to apply the commit and rebuild and deploy only that mo...

### Impact It's possible to execute any SQL query in Oracle by using the function like [DBMS_XMLGEN or DBMS_XMLQUERY](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_XMLGEN.html). The XWiki query validator does not sanitize functions that would be used in a simple `select` and Hibernate allows using any native function in an HQL query. ### Patches This has been patched in 16.10.2, 16.4.7 and 15.10.16. ### Workarounds There is no known workaround, other than upgrading XWiki. ### References https://jira.xwiki.org/browse/XWIKI-22734 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:[email protected])