XWiki Platform is a generic wiki platform. Starting in version 6.2-milestone-1, one can execute any wiki content with the right of IconThemeSheet author by creating an icon theme with certain content. This can be done by creating a new page or even through the user profile for users not having edit right. The issue has been patched in XWiki 14.9, 14.4.6, and 13.10.10. An available workaround is to fix the bug in the page IconThemesCode.IconThemeSheet by applying a modification from commit 48caf7491595238af2b531026a614221d5d61f38.

XWiki Platform is a generic wiki platform. Starting in version 13.10, it's possible to use the right of an existing document content author to execute a text area property. This has been patched in XWiki 14.10, 14.4.7, and 13.10.11. There are no known workarounds.

XWiki Platform is a generic wiki platform. Starting in versions 6.3-rc-1 and 6.2.4, it's possible to inject arbitrary wiki syntax including Groovy, Python and Velocity script macros via the newThemeName request parameter (URL parameter), in combination with additional parameters. This has been patched in the supported versions 13.10.10, 14.9-rc-1, and 14.4.6. As a workaround, it is possible to edit FlamingoThemesCode.WebHomeSheet and manually perform the changes from the patch fixing the issue.

XWiki Platform is a generic wiki platform. Starting in version 11.6-rc-1, comments are supposed to be executed with the right of superadmin but in restricted mode (anything dangerous is disabled), but the async macro does not take into account the restricted mode. This means that any user with comment right can use the async macro to make it execute any wiki content with the right of superadmin. This has been patched in XWiki 14.9, 14.4.6, and 13.10.10. The only known workaround consists of applying a patch and rebuilding and redeploying org.xwiki.platform:xwiki-platform-rendering-async-macro.

XWiki Platform is a generic wiki platform. Starting in version 2.3-milestone-1, the annotation displayer does not execute the content in a restricted context. This allows executing anything with the right of the author of any document by annotating the document. This has been patched in XWiki 13.10.11, 14.4.7 and 14.10. There is no easy workaround except to upgrade.

XWiki Commons are technical libraries common to several other top level XWiki projects. Starting in version 3.1-milestone-1, any user can edit their own profile and inject code, which is going to be executed with programming right. The same vulnerability can also be exploited in all other places where short text properties are displayed, e.g., in apps created using Apps Within Minutes that use a short text field. The problem has been patched on versions 13.10.9, 14.4.4, 14.7RC1.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions 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 UIX parameters. A proof of concept exploit is to log in, add an XWiki.UIExtensionClass xobject to the user profile page, with an Extension Parameters content containing label={{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}}. Then, navigating to PanelsCode.ApplicationsPanelConfigurationSheet (i.e., <xwiki-host>/xwiki/bin/view/PanelsCode/ApplicationsPanelConfigurationSheet where <xwiki-host> is the URL of your XWiki installation) should not execute the Groovy script. If it does, you will see Hello from groovy! displayed on the screen. This vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10-rc-1. Users are advised to upgrade. For users unable to upgrade the issue can be fixed by editing the PanelsCode.ApplicationsPanelConfigurationSheet wiki page and making the same modifications as shown in commit 6de5442f3c.

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.

Patches This has been patched in XWiki 13.10.11, 14.4.8, 14.10.2 and 15.0RC1.

Workarounds There is no workaround apart from upgrading.

References https://jira.xwiki.org/browse/XWIKI-20327 https://github.com/xwiki/xwiki-platform/commit/0d547181389f7941e53291af940966413823f61c

For more information

If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List

Impact

Steps to reproduce:

Open <xwiki-host>/xwiki/bin/view/XWiki/Notifications/Code/LegacyNotificationAdministration?since=%7B%7B%2Fhtml%7D%7D+%7B%7Basync+async%3D%22true%22+cached%3D%22false%22+context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello+%22+%2B+%22from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D, where <xwiki-host> is the URL of your XWiki installation.

This demonstrates an XWiki syntax injection attack via the since-parameter, allowing privilege escalation from view to programming rights.

Patches

The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8 and 14.10.3.

Workarounds

For versions >= 14.6-rc-1 the workaround is to modify the page XWiki.Notifications.Code.LegacyNotificationAdministration to add the missing escaping, as described on https://github.com/xwiki/xwiki-platform/commit/8e7c7f90f2ddaf067cb5b83b181af41513028754#diff-4e13f4ee4a42938bf1201b7ee71ca32edeacba22559daf0bcb89d534e0225949R70

For versions < 14.6-rc-1 the workaround is to modify the file <xwikiwebapp>/templates/distribution/eventmigration.wiki to add the missing escaping, as described on https://github.com/xwiki/xwiki-platform/commit/6d74e2e4aa03d19f0be385ab63ae9e0f0e90a766

References

https://jira.xwiki.org/browse/XWIKI-20287

For more information

If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List

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 document as shown in the patch.

References

https://jira.xwiki.org/browse/XWIKI-20268 https://github.com/xwiki/xwiki-platform/commit/7bf7094f8ffac095f5d66809af7554c9cc44de09

For more information

If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List

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 Email us at Security Mailing List

Impact

Any user with the right to add an object on a page 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 the styles properties FlamingoThemesCode.WebHome. This page is installed by default.

Reproduction Steps

Steps to reproduce:

- As a user without script or programming rights, edit your user profile with the object editor (enable advanced mode if necessary to get access) and add an object of type "Theme Class" of "FlamingoThemesCode". In the field "body-bg" (all other fields should work, too) add the following text:

{{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}}

- Click "Save & View" - Open <xwiki-host>/xwiki/bin/view/FlamingoThemesCode/WebHomeSheet where <xwiki-host> is the URL of your XWiki installation

Expected result:

The list of color themes either doesn't include the user's profile or displays a regular preview.

Actual result:

The user's profile is listed as color theme but instead of the little preview the message

Failed to execute the [html] macro. Cause: [When using HTML content inline, you can only use inline HTML content. Block HTML content (such as tables) cannot be displayed. Try leaving an empty line before and after the macro.]. Click on this message for details. Hello from groovy!">

is displayed. This shows that a Groovy macro with content created by the user has been executed and thus demonstrates a privilege escalation from simple user account to programming rights.

Patches The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10.

Workarounds The issue can be fixed by applying this patch on FlamingoThemesCode.WebHomeSheet.

References - patch: https://github.com/xwiki/xwiki-platform/commit/df596f15368342236f8899ca122af8f3df0fe2e8 - Jira: https://jira.xwiki.org/browse/XWIKI-20280

For more information If you have any questions or comments about this advisory:

Open an issue in Jira XWiki.org Email us at Security Mailing List

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with edit rights on a page (e.g., it's own user page), 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 the section ids in XWiki.AdminFieldsDisplaySheet. This page is installed by default. The vulnerability has been patched in XWiki versions 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11.

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 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 Email us at Security Mailing List

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 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 Email us at Security Mailing List

Impact Any user with edit rights on a page (e.g., it's own user page), 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 the information loaded from attachments in imported.vm, importinline.vm, and packagelist.vm. This page is installed by default.

Reproduction steps are described in https://jira.xwiki.org/browse/XWIKI-20267

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 on imported.vm, importinline.vm, and packagelist.vm.

References - https://github.com/xwiki/xwiki-platform/commit/e4bbdc23fea0be4ef1921d1a58648028ce753344 - https://jira.xwiki.org/browse/XWIKI-20267

For more information

If you have any questions or comments about this advisory:

Open an issue in Jira XWiki.org Email us at Security Mailing List

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 is enough to fix the issue.

References - https://github.com/xwiki/xwiki-platform/commit/d7e56185376641ee5d66477c6b2791ca8e85cfee - https://jira.xwiki.org/browse/XWIKI-20456

For more information

If you have any questions or comments about this advisory:

- Open an issue in Jira XWiki.org - Email us at Security Mailing List

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, only escaped <script> and <style>-tags but neither attributes that can be used to inject scripts nor other dangerous HTML tags like <iframe>. 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.6 RC1 with the introduction of a filter with allowed HTML elements and attributes that is enabled in restricted mode. There are no known workarounds apart from upgrading to a version including the fix.

XWiki Commons are technical libraries common to several other top level XWiki projects. The RSS macro that is bundled in XWiki included the content of the feed items without any cleaning in the HTML output when the parameter content was set to true. This allowed arbitrary HTML and in particular also JavaScript injection and thus cross-site scripting (XSS) by specifying an RSS feed with malicious content. With the interaction of a user with programming rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content and sabotaging the wiki. The issue has been patched in XWiki 14.6 RC1, the content of the feed is now properly cleaned before being displayed. As a workaround, if the RSS macro isn't used in the wiki, the macro can be uninstalled by deleting WEB-INF/lib/xwiki-platform-rendering-macro-rss-XX.jar, where XX is XWiki's version, in the web application's directory.

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 Email us at Security Mailing List

Impact

Steps to reproduce:

It is possible to trick a user with programming rights into visiting <xwiki-host>/xwiki/bin/view/XWiki/LoggingAdmin?loggeractionset=1&loggername=%7B%7Bcache%7D%7D%7B%7Bgroovy%7D%7Dnew+File%28%22%2Ftmp%2Fexploit.txt%22%29.withWriter+%7B+out+-%3E+out.println%28%22created+from+notification+filter+preferences%21%22%29%3B+%7D%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D&loggerlevel=TRACE where <xwiki-host> is the URL of your XWiki installation, e.g., by embedding an image with this URL in a document that is viewed by a user with programming rights.

Expected result:

No file in /tmp/exploit.txt has been created.

Actual result:

The file /tmp/exploit.txt is been created with content "created from notification filter preferences!". This demonstrates a CSRF remote code execution vulnerability that could also be used for privilege escalation or data leaks (if the XWiki installation can reach remote hosts).

Patches The problem has been patched on XWiki 14.4.7, and 14.10.

Workarounds The issue can be fixed manually applying this patch.

References - https://jira.xwiki.org/browse/XWIKI-20291 - https://github.com/xwiki/xwiki-platform/commit/49fdfd633ddfa346c522d2fe71754dc72c9496ca

For more information If you have any questions or comments about this advisory:

Open an issue in Jira XWiki.org Email us at Security Mailing List

XWiki Commons are technical libraries common to several other top level XWiki projects. The Livetable Macro wasn't properly sanitizing column names, thus allowing the insertion of raw HTML code including JavaScript. This vulnerability was also exploitable via the Documents Macro that is included since XWiki 3.5M1 and doesn't require script rights, this can be demonstrated with the syntax {{documents id="example" count="5" actions="false" columns="doc.title, before<script>alert(1)</script>after"/}}. Therefore, this can also be exploited by users without script right and in comments. With the interaction of a user with more rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content. This has been patched in XWiki 14.9, 14.4.6, and 13.10.10.

Impact

HTML rendering didn't check for dangerous attributes/attribute values. This allowed cross-site scripting (XSS) attacks via attributes and link URLs, e.g., supported in XWiki syntax.

Patches This has been patched in XWiki 14.6 RC1.

Workarounds There are no known workarounds apart from upgrading to a fixed version.

References https://github.com/xwiki/xwiki-rendering/commit/c40e2f5f9482ec6c3e71dbf1fff5ba8a5e44cdc1 https://jira.xwiki.org/browse/XRENDERING-663

For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List

XWiki Platform is a generic wiki platform. Starting in version 12.10, a user without script rights can introduce a stored cross-site scripting by using the Live Data macro. This has been patched in XWiki 14.9, 14.4.7, and 13.10.10. There are no known workarounds.

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 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 Email us at Security Mailing List

XWiki Platform is a generic wiki platform. Starting in version 14.3-rc-1, org.xwiki.store.script.TemporaryAttachmentsScriptService#uploadTemporaryAttachment returns an instance of com.xpn.xwiki.doc.XWikiAttachment. This class is not supported to be exposed to users without the programing right. com.xpn.xwiki.api.Attachment should be used instead and takes case of checking the user's rights before performing dangerous operations. This has been patched in versions 14.9-rc-1 and 14.4.6. There are no known workarounds for this issue.

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 Email us at Security Mailing List

Attribution

This vulnerability has been reported on Intigriti by Mete.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions any user with edit rights on a document can trigger an XAR import on a forged XAR file, leading to the ability to display the content of any file on the XWiki server host. This vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10-rc-1. Users are advised to upgrade. Users unable to upgrade may apply the patch e3527b98fd manually.

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 be applied by patching the affected wiki documents, the most important one being AppWithinMinutes.LiveTableEditSheet. Further, the attack can be prevented by denying view access to AppWithinMinutes.LiveTableEditSheet. This only impacts creation and editing of App Within Minutes apps.

References

https://jira.xwiki.org/browse/XWIKI-20190 https://github.com/xwiki/xwiki-platform/commit/e73b890623efa604adc484ad82f37e31596fe1a6

For more information

If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List

XWiki Commons are technical libraries common to several other top level XWiki projects. Rights added to a document are not taken into account for viewing it once it's deleted. Note that this vulnerability only impact deleted documents that where containing view rights: the view rights provided on a space of a deleted document are properly checked. The problem has been patched in XWiki 14.10 by checking the rights of current user: only admin and deleter of the document are allowed to view it.