#jira

### Impact Triggering the office converter with a specially crafted file name allows writing the attachment's content to an attacker-controlled location on the server as long as the Java process has write access to that location. In particular in the combination with attachment moving, a feature introduced in XWiki 14.0, this is easy to reproduce but it also possible to reproduce in versions as old as XWiki 3.5 by uploading the attachment through the REST API which doesn't remove `/` or `\` from the filename. As the mime type of the attachment doesn't matter for the exploitation, this could e.g., be used to replace the `jar`-file of an extension which would allow executing arbitrary Java code and thus impact the confidentiality, integrity and availability of the XWiki installation. To reproduce the issue on versions since XWiki 14.0, execute the following steps: 1. Activate the office server 2. Upload an arbitrary file with the extension .doc, e.g., to your user profile (you can us...

### Impact The footnote macro executed its content in a potentially different context than the one in which it was defined. In particular in combination with the include macro, this allows privilege escalation from a simple user account in XWiki to programming rights and thus remote code execution, impacting the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, perform the following steps: 1. Edit your user profile with the object editor and add an object of type DocumentSheetBinding with value XWiki.ClassSheet 2. Edit your user profile with the wiki editor and add the syntax `{{footnote}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/footnote}}` When the text "Hello from groovy!" is displayed at the bottom of the document, the installation is vulnerable. Instead, an error should be displayed. ### Patches This vulnerability has been patched in XWiki 14.10.6 and 15.1-rc-1. ### Workarounds There is no workaround apart from upgradi...

### Impact When a document has been deleted and re-created, it is possible for users with view right on the re-created document but not on the deleted document to view the contents of the deleted document. Such a situation might arise when rights were added to the deleted document. This can be exploited through the diff feature and, partially, through the REST API by using versions such as `deleted:1` (where the number counts the deletions in the wiki and is thus guessable). Given sufficient rights, the attacker can also re-create the deleted document, thus extending the scope to any deleted document as long as the attacker has edit right in the location of the deleted document. ### Patches This vulnerability has been patched in XWiki 14.10.8 and 15.3 RC1 by properly checking rights when deleted revisions of a document are accessed. ### Workarounds The only workaround is to regularly [clean deleted documents](https://extensions.xwiki.org/xwiki/bin/view/Extension/Index%20Application#...

### Impact An attacker with edit access on any document (can be the user profile which is editable by default) can move any attachment of any other document to this attacker-controlled document. This allows the attacker to access and possibly publish any attachment of which the name is known, regardless if the attacker has view or edit rights on the source document of this attachment. Further, the attachment is deleted from the source document. This vulnerability exists since the introduction of attachment move support in XWiki 14.0 RC1. ### Patches This vulnerability has been patched in XWiki 14.4.8, 14.10.4, and 15.0 RC1. ### Workarounds There is no workaround apart from upgrading to a fixed version. ### References * https://jira.xwiki.org/browse/XWIKI-20334 * https://github.com/xwiki/xwiki-platform/commit/d7720219d60d7201c696c3196c9d4a86d0881325 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://ji...

### Impact Any user who can edit their own user profile can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. This can be reproduced with the following steps: 1. As an advanced user, use the object editor to add an object of type `UIExtensionClass` to your user profile. Set the value "Extension Point ID" to `{{/html}}{{async async=false cache=false}}{{groovy}}println("Hello from Groovy!"){{/groovy}}{{/async}}` 2. Open `<xwiki-host>/xwiki/bin/edit/XWiki/<username>?sheet=Menu.UIExtensionSheet` where `<xwiki-host>` is the URL of your XWiki installation and `<username>` is your user name. If the text `Hello from Groovy!" selected="selected">` is displayed in the output, the attack succeeded. ### Patches This has been patched in XWiki 14.10.8 and 15.3 RC1 by adding proper escaping. ### Workarounds The [patch](https://github.com/xwiki/xwiki-platform/commit/9e8f080094333de...

### Impact The cleaning of attributes during XHTML rendering, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid attribute names. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki: ``` [[Link1>>https://XWiki.example.com||/onmouseover="alert('XSS1')"]] ``` When a user moves the mouse over this link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. While this attribute was correctly recognized as not allowed, the attribute was still printed with a prefix `data-xwiki-translated-attribute-` without further cleaning or validation. Note that while versions below 14.6 are not vulnerable to this particular vulnerability, the...

XWiki Rendering is a generic Rendering system that converts textual input in a given syntax into another syntax. The cleaning of attributes during XHTML rendering, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid attribute names. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki. When a user moves the mouse over a malicious link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. While this attribute was correctly recognized as not allowed, the attribute was still printed with a prefix `data-xwiki-translated-attribute-` without further cleaning or validation. This problem has been patched in XWiki 14.10.4 and 15.0 RC1 by ...

XWiki Rendering is a generic Rendering system that converts textual input in a given syntax into another syntax. Prior to version 14.10.6 of `org.xwiki.platform:xwiki-core-rendering-macro-footnotes` and `org.xwiki.platform:xwiki-rendering-macro-footnotes` and prior to version 15.1-rc-1 of `org.xwiki.platform:xwiki-rendering-macro-footnotes`, the footnote macro executed its content in a potentially different context than the one in which it was defined. In particular in combination with the include macro, this allows privilege escalation from a simple user account in XWiki to programming rights and thus remote code execution, impacting the confidentiality, integrity and availability of the whole XWiki installation. This vulnerability has been patched in XWiki 14.10.6 and 15.1-rc-1. There is no workaround apart from upgrading to a fixed version of the footnote macro.

### Impact When login via the OAuth method, the identityOAuth parameters, sent in a GET request is vulnerable to XSS and XWiki syntax injection. This allows remote code execution via the groovy macro and thus affects the confidentiality, integrity and availability of the whole XWiki installation. The vulnerability is in [this part](https://github.com/xwikisas/identity-oauth/blob/master/ui/src/main/resources/IdentityOAuth/LoginUIExtension.vm#L58) of the code. ### Patches The issue has been fixed in Identity OAuth version 1.6 by https://github.com/xwikisas/identity-oauth/commit/d805d3154b17c6bf455ddf5deb0a3461a3833bc6 . The fix is in the content of the [IdentityOAuth/LoginUIExtension](https://github.com/xwikisas/identity-oauth/commit/d805d3154b17c6bf455ddf5deb0a3461a3833bc6#diff-2ab2e0716443d790d7d798320e4a45151661f4eca5440331f4a227b29c87c188) file ### Workarounds There are no known workarounds besides upgrading. ### References _Are there any links users can visit to find out more?...

### Impact It's possible for a user without any specific right to perform script injection and remote code execution just by inserting an appropriate title when creating a new Change Request. This vulnerability is particularly critical as Change Request aims at being created by user without any particular rights. ### Patches The vulnerability has been fixed in Change Request 1.9.2. ### Workarounds It's possible to workaround the issue without upgrading by editing the document `ChangeRequest.Code.ChangeRequestSheet` and by performing the same change as in the commit: https://github.com/xwiki-contrib/application-changerequest/commit/7565e720117f73102f5a276239eabfe85e15cff4. ### References * JIRA ticket: https://jira.xwiki.org/browse/CRAPP-298 * Commit of the fix: https://github.com/xwiki-contrib/application-changerequest/commit/7565e720117f73102f5a276239eabfe85e15cff4 ### For more information If you have any questions or comments about this advisory: * Open an issue in [J...