#java

### Impact A registered user can perform remote code execution leading to privilege escalation by injecting the proper code in the "property" field of an attachment selector, as a gadget of their own dashboard. Note that the vulnerability does not impact comments of a wiki. ### Patches The vulnerability has been patched in XWiki 13.10.11, 14.4.8, 14.10.2, 15.0-rc-1. ### Workarounds The problem can be worked around by applying following changes directly in XWiki.AttachmentSelector page: https://github.com/xwiki/xwiki-platform/commit/5e8725b4272cd3e5be09d3ca84273be2da6869c1. ### References * https://jira.xwiki.org/browse/XWIKI-20364 * https://github.com/xwiki/xwiki-platform/commit/5e8725b4272cd3e5be09d3ca84273be2da6869c1 ### 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])

### Impact Any user with view rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of `Invitation.InvitationCommon`. This page is installed by default. See https://jira.xwiki.org/browse/XWIKI-20283 for the reproduction steps. ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11. ### Workarounds The issue can be fixed by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/3d055a0a5ec42fdebce4d71ee98f94553fdbfebf) on `Invitation.InvitationCommon`. ### References - https://github.com/xwiki/xwiki-platform/commit/3d055a0a5ec42fdebce4d71ee98f94553fdbfebf - https://jira.xwiki.org/browse/XWIKI-20283 ### 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])

### Impact The office document viewer macro was allowing anyone to see any file content from the hosting server, provided that the office server was connected and depending on the permissions of the user running the servlet engine (e.g. tomcat) running XWiki. The same vulnerability also allowed to perform internal requests to resources from the hosting server. ### Patches The problem has been patched in XWiki 13.10.11, 14.10.1, 14.4.8, 15.0-rc-1. ### Workarounds It might be possible to workaround this vulnerability by running XWiki in a sandbox with a user with very low privileges on the machine, now to run a servlet engine the user will always need access to some files, so in any case this workaround won't protect all files to be accessed. ### References * Original jira ticket: https://jira.xwiki.org/browse/XWIKI-20447 * Jira ticket related to another exploit using same root cause: https://jira.xwiki.org/browse/XWIKI-20324 * Jira ticket related to the possibility to explo...

### Impact Any user with view rights on `XWiki.AttachmentSelector` can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping in the "Cancel and return to page" button. This page is installed by default. See https://jira.xwiki.org/browse/XWIKI-20275 for the reproduction steps. ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11. ### Workarounds The issue can be fixed by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/aca1d677c58563bbe6e35c9e1c29fd8b12ebb996) on `XWiki.AttachmentSelector`. ### References - https://github.com/xwiki/xwiki-platform/commit/aca1d677c58563bbe6e35c9e1c29fd8b12ebb996 - https://jira.xwiki.org/browse/XWIKI-20275 ### 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](mailt...

### Impact Any user who can create a space can become admin of that space through App Within Minutes. The admin right implies the script right and thus allows JavaScript injection. The vulnerability can be exploited by creating an app in App Within Minutes. If the button should be disabled because the user doesn't have global edit right, the app can also be created by directly opening `/xwiki/bin/view/AppWithinMinutes/CreateApplication?wizard=true` on the XWiki installation. ### Patches This has been patched in XWiki 13.10.11, 14.4.8, 14.10.1 and 15.0 RC1 by not granting the space admin right if the user doesn't have script right on the space where the app is created. Error message are displayed to warn the user that the app will be broken in this case. Users who became space admin through this vulnerability won't loose the space admin right due to the fix, so it is advised to check if all users who created AWM apps should keep their space admin rights. ### Workarounds The patch can ...

### Impact Any user with edit rights on any document (e.g., the own user profile) can execute code with programming rights, leading to remote code execution by following these steps: 1. Set the title of any document you can edit (can be the user profile) to ``` {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}} ``` 2. Use the object editor to add an object of type `XWiki.TemplateProviderClass` (named "Template Provider Class") to that document. 3. Go to another document you can view (can be the home page) and append `?sheet=XWiki.AdminTemplatesSheet` to the URL. When the attack is successful, a template with name "Hello from groovy!" is displayed in the list while on fixed systems, the full title should be displayed. ### Patches This vulnerability has been patched in XWiki 13.10.11, 14.4.8, 14.10.1 and 15.0 RC1. ### Workarounds The vulnerability can be fixed by patching the code in the affected XWiki...

### Impact If a guest has view rights on any document, it's possible to create a new user using the `distribution/firstadminuser.wiki` in the wrong context. To reproduce: * On a wiki with view rights for guests but user registration disabled, open as guest <server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%2F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7Btemplate+name%3D%22distribution%2Ffirstadminuser.wiki%22+%2F%7D%7D where <server> is the URL of your XWiki installation. * Enter username and password of your choice. * Click "Register and login" ### Patches The vulnerability has been patched in XWiki 15.0-rc-1 and 14.10.1. ### Workarounds There is no known workaround other than upgrading. ### References https://jira.xwiki.org/browse/XWIKI-19852 https://jira.xwiki.org/browse/XWIKI-20400 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwik...

### Impact A payments info page of Pay is susceptible to reflected Cross-site scripting. An attacker could create a working URL that renders a javascript link to a user on a Rails application that integrates Pay. This URL could be distributed via email to specifically target certain individuals. If the targeted application contains a functionality to submit user-generated content (such as comments) the attacker could even distribute the URL using that functionality. ### Patches This has been patched in version 6.3.2 and above. Pay will now sanitize the `back` parameter and only permit relative paths.

### Impact The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1 and massively improved in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid HTML comments. As a consequence, any code relying on this "restricted" mode for security is vulnerable to JavaScript injection ("cross-site scripting"/XSS). An example are anonymous comments in XWiki where the HTML macro filters HTML using restricted mode: ```html {{html}} <!--> <Details Open OnToggle=confirm("XSS")> {{/html}} ``` When a privileged user with programming rights visits such a comment in XWiki, the malicious JavaScript code is executed in the context of the user session. This allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. Note that while all versions since 4.2-milestone-1 should be vulnerable, only starting with version 14.6-rc-1 the HTML comment is...

XWiki Commons are technical libraries common to several other top level XWiki projects. The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1 and massively improved in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid HTML comments. As a consequence, any code relying on this "restricted" mode for security is vulnerable to JavaScript injection ("cross-site scripting"/XSS). When a privileged user with programming rights visits such a comment in XWiki, the malicious JavaScript code is executed in the context of the user session. This allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. This problem has been patched in XWiki 14.10, HTML comments are now removed in restricted mode and a check has been introduced that ensures that comments don't start with `>`. There are no known workarounds apart from upgrading to ...