#jira

### Impact It's possible to display any page you cannot access through the combination of the async and display macro. Steps to reproduce: 1. Enable comments for guests by giving guests comment rights 2. As a guest, create a comment with content ```{{async}}{{display reference="Menu.WebHome" /}}{{/async}}``` 3. Open the comments viewer from the menu (appends ?viewer=comments to the URL) -> the `Menu.WebHome` is displayed while the expectation would be to have an error that the current user is not allowed to see it ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8, and 13.10.11. ### Workarounds There is no known workaround. ### References https://jira.xwiki.org/browse/XWIKI-20394 https://jira.xwiki.org/browse/XRENDERING-694 ### 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 It's possible to execute anything with the right of the Scheduler Application sheet page. To reproduce: 1. As a user without script or programming rights, edit your user profile with the object editor and add a new object of type XWiki.SchedulerJobClass (search for "Scheduler") 1. In "Job Script", add the following ```{{/code}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy} {{/async}}``` 1. Click "Save & View" 1. If the job information isn't already displayed (you should see "Job Name", "Job Description", etc.), append ?sheet=XWiki.SchedulerJobSheet to the URL. ### Patches This has been patched in XWiki 14.10.3 and 15.0 RC1. ### Workarounds While the fix in the scheduler itself is easy, it relies on the code macro `source` parameter, which was introduced in 14.10.2 so you have to upgrade to benefit from it. ### References https://jira.xwiki.org/browse/XWIKI-20295 https://jira.xwiki.org/browse/XWIK...

### 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. The following syntax, to be put, e.g., in the about section of the user profile, demonstrates a proof of concept: ``` {{html wiki="true"}}~{~{~/~h~t~m~l~}~}~ ~{~{~c~a~c~h~e~}~}~{~{~g~r~o~o~v~y~}~}~p~r~i~n~t~l~n~(~1~)~{~{~/~g~r~o~o~v~y~}~}~{~{~/~c~a~c~h~e~}~}~{{/html}} ``` While it would be expected that the above code is displayed just without the `~`, in fact just "1" is displayed, followed by a lot of raw HTML code. The same vulnerability can also be exploited in other contexts where the `display` method on a document is used to display a field with wiki syntax, for example in applications created using [App Within Minutes](https://extensions.xwiki.org/xwiki/bin/view/Extension/App%20Within%20Minutes%20Application). ### Patches This has been patched in XWiki...

### Impact Any user with view rights 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. The attack works by opening a non-existing page with a name crafted to contain a dangerous payload. For instance: `Open <xwiki-host>/xwiki/bin/view/%22%2F%7D%7D%7B%7B%2Fhtml%7D%7D%20%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22Hello%20%22%20%2B%20%22from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D?sheet=XWiki.ClassSheet&xpage=view`, where `<xwiki-host>` is the URL of your XWiki installation. ### Patches This has been patched in XWiki 14.4.8, 14.10.3 and 15.0RC1. ### Workarounds The fix is only impacting Velocity templates and page contents, so applying this [patch](https://github.com/xwiki/xwiki-platform/commit/d7e56185376641ee5d66477c6b2791ca8e85cfee) is enough to fix the issue. ### Refere...

### 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 `Macro.VFSTreeMacro`. This page is not installed by default. See https://jira.xwiki.org/browse/XWIKI-20260 for the reproduction steps. ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.2, 14.4.8, 13.10.11. ### Workarounds The issue can be fixed by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/fad02328f5ec7ab7fe5b932ffb5bc5c1ba7a5b12) on `Macro.VFSTreeMacro`. ### References - https://jira.xwiki.org/browse/XWIKI-20260 - https://github.com/xwiki/xwiki-platform/commit/fad02328f5ec7ab7fe5b932ffb5bc5c1ba7a5b12 ### 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 It's possible to break many translations coming from wiki pages by creating a corrupted document containing a translation object. ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11. ### Workarounds There is no other workaround other than fixing any way to create a document that fail to load. ### References https://jira.xwiki.org/browse/XWIKI-20460 ### 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 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...