#jira

### Impact The XML export of a page in XWiki that can be triggered by any user with view rights on a page by appending `?xpage=xml` to the URL includes password and email properties stored on a document that aren't named `password` or `email`. This allows any user to obtain the salted and hashed user account validation or password reset token. As those tokens are randomly generated strings, the immediate impact of this should be low. The user's password and email itself aren't exposed as those fields are named `password` and `email` and thus aren't affected. However, depending on how the wiki is used, there could be extensions or custom code that store passwords in plain text in such password properties that would be exposed by this vulnerability. ### Patches This vulnerability has been fixed by completely removing the output of password and email fields in this XML export in versions 17.2.0 RC1, 16.10.5 and 16.4.7. ### Workarounds If this XML export isn't needed, the file `templates...

### Impact Any user with edit right on a page of the wiki can create an XClass with a database list property that references a password property, for example the password hash that is stored for users. When adding an object of that XClass, the content of that password property is displayed. In practice, with a standard rights setup, this means that any user with an account on the wiki can access password hashes of all users, and possibly other password properties (with hashed or plain storage) that are on pages that the user can view. ### Patches This vulnerability has been pached in XWiki 16.4.7, 16.10.5, and 17.2.0 by disallowing the use of password properties in database list properties. Additionally, queries for email properties are disallowed, too, when email obfuscation is enabled. ### Workarounds We're not aware of any workarounds.

### Impact Reflected XSS vulnerabilities in two templates allow an attacker to execute malicious JavaScript code in the context of the victim's session by getting the victim to visit an attacker-controlled URL. PoC URLs are `/xwiki/bin/view/Main/?xpage=job_status_json&jobId=asdf&translationPrefix=<img src=1 onerror=alert(document.domain)>` and `/xwiki/bin/view/Main/?xpage=distribution&extensionId=%3Cimg src=x onerror=alert(document.domain)%3E&extensionVersionConstraint=%3Cimg src=x onerror=alert(document.domain)%3E`. This allows the attacker to perform arbitrary actions using the permissions of the victim. ### Patches The problem has been patched in XWiki 16.4.8, 16.10.6 and 17.3.0RC1 by adding escaping in the affected templates. ### Workarounds The affected templates can be patched manually in the WAR by applying the same changes as in [the patch](https://github.com/xwiki/xwiki-platform/commit/e5926a938cbecc8b1eaa48053d8d370cff107cb0). ### Attribution The vulnerability involving `...

### 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#searchDocuments APIs are not sanitizing the query at all and even if they force a specific select, Hibernate allows using any native function in an HQL query (for example in the WHERE). ### Patches This has been patched in 16.10.6 and 17.3.0-rc-1. ### Workarounds There is no known workaround, other than upgrading XWiki. ### References https://jira.xwiki.org/browse/XWIKI-22728 ### 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:security@xwiki.org)

### Impact It's possible for anyone to inject SQL using the parameter sort of the `getdeleteddocuments.vm`. It's injected as is as an ORDER BY value. One can see the result of the injection with http://127.0.0.1:8080/xwiki/rest/liveData/sources/liveTable/entries?sourceParams.template=getdeleteddocuments.vm&sort=injected (this example does not work, but it shows that an HQL query was executed with the passed value which look nothing like an order by value, without any kind of sanitation). ### Patches This has been patched in 17.3.0-rc-1, 16.10.6. ### Workarounds There is no known workaround, other than upgrading XWiki. ### References https://jira.xwiki.org/browse/XWIKI-23093 ### 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:security@xwiki.org) ### Attribution The vulnerability was identifier by Aleksey Solovev from Positive Technologies.

### Impact The default macro content parser didn't preserve the restricted attribute of the transformation context when executing nested macros. This allows executing macros that are normally forbidden in restricted mode, in particular script macros. The [cache](https://extensions.xwiki.org/xwiki/bin/view/Extension/Cache%20Macro) and [chart](https://extensions.xwiki.org/xwiki/bin/view/Extension/Chart%20Macro) macros that are bundled in XWiki use the vulnerable feature. The following XWiki syntax, when used inside a comment in XWiki, demonstrates the privilege escalation from comment right to programming right and thus remote code execution (RCE) that is possible due to this: ``` {{cache}}{{groovy}}println("Hello from Groovy!"){{/groovy}}{{/cache}} ``` This vulnerability exists since the restricted attribute has been added to the transformation context in version 4.2. ### Patches This has been patched in XWiki 13.10.11, 14.4.7 and 14.10. ### Workarounds To avoid the exploitation of...

### Impact The XHTML syntax depended on the `xdom+xml/current` syntax which allows the creation of raw blocks that permit the insertion of arbitrary HTML content including JavaScript. This allows XSS attacks for users who can edit a document like their user profile (enabled by default). The attack works by setting the document's syntax to `xdom+xml/current` and then inserting content like ``` <document><p><metadata><metadata><entry><string>syntax</string><org.xwiki.rendering.syntax.Syntax><type><name>XHTML</name><id>xhtml</id><variants class="empty-list"></variants></type><version>5</version></org.xwiki.rendering.syntax.Syntax></entry></metadata></metadata></p><rawtext syntax="html/5.0" content="&lt;script&gt;alert(1);&lt;/script&gt;"></rawtext></document> ``` This has been fixed by removing the dependency on the `xdom+xml/current` syntax from the XHTML syntax. Note that the `xdom+xml` syntax is still vulnerable to this attack. As it's main purpose is testing and its use is quite diff...

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.