#jira

### Impact When trying to create a document that already exists, XWiki displays an error message in the form for creating it. Due to missing escaping, this error message is vulnerable to raw HTML injection and thus XSS. The injected code is the document reference of the existing document so this requires that the attacker first creates a non-empty document whose name contains the attack code. To reproduce, the following steps can be used: 1. Go to `<xwiki-host>/xwiki/bin/create/Main/WebHome?parent=&templateprovider=&spaceReference=&name=%3Cimg%20onerror=%22alert(1)%22%20src=%22test%22` where `<xwiki-host>` is the URL of your XWiki installation. 2. Create the page and add some content. 3. Go again to `<xwiki-host>/xwiki/bin/create/Main/WebHome?parent=&templateprovider=&spaceReference=&name=%3Cimg%20onerror=%22alert(1)%22%20src=%22test%22` where `<xwiki-host>` is the URL of your XWiki installation. If an alert with content "1" is displayed, the installation is vulnerable. This allows...

### Impact When document names are validated according to a name strategy (disabled by default), XWiki is vulnerable to a reflected XSS attack in the page creation form. To reproduce, make sure that "Validate names before saving" is enabled in the administration under "Editing" -> "Name strategies" and then open `<xwiki-host>/xwiki/bin/create/Main/%3Cscript%3Ealert%28%27Test%20Test%20Test%20Test%20Test%27%29%3C%2Fscript%3E` where `<xwiki-host>` is the URL of your XWiki installation. This displays an alert if the installation is vulnerable. This allows an attacker to execute arbitrary actions with the rights of the user opening the malicious link. Depending on the rights of the user, this may allow remote code execution and full read and write access to the whole XWiki installation. ### Patches This has been patched in XWiki 14.10.12 and 15.5RC1 by adding appropriate escaping. ### Workarounds The vulnerable template file `createinline.vm` is part of XWiki's WAR and can be patched by m...

### Impact In XWiki, it is possible to pass a title to the page creation action that isn't displayed at first but then executed in the second step. This can be used by an attacker to trick a victim to execute code, allowing script execution if the victim has script right or remote code execution including full access to the XWiki instance if the victim has programming right. For the attack to work, the attacker needs to convince the victim to visit a link like `<xwiki-host>/xwiki/bin/create/NonExistingSpace/WebHome?title=$services.logging.getLogger(%22foo%22).error(%22Script%20executed!%22)` where `<xwiki-host>` is the URL of the Wiki installation and to then click on the "Create" button on that page. The page looks like a regular XWiki page that the victim would also see when clicking the button to create a page that doesn't exist yet, the malicious code is not displayed anywhere on that page. After clicking the "Create" button, the malicious title would be displayed but at this poi...

### Impact An attacker can create a template provider on any document that is part of the wiki (could be the attacker's user profile) that contains malicious code. This code is executed when this template provider is selected during document creation which can be triggered by sending the user to a URL. For the attacker, the only requirement is to have an account as by default the own user profile is editable. This allows an attacker to execute arbitrary actions with the rights of the user opening the malicious link. Depending on the rights of the user, this may allow remote code execution and full read and write access to the whole XWiki installation. For reproduction, the following steps can be used: 1. As a simple user with no script right, edit the user profile with the object editor and add an object of type "Template Provider Class". Set the name to "My Template", set template to any page on the wiki. In "Creation Restrictions", enter `<img onerror="alert(1)" src="https://www.ex...

### 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...