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

XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with edit 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 the included pages in the included documents edit panel. The problem has been patched on XWiki 14.4.7, and 14.10.

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

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 Wiki UI Main Wiki is software for managing subwikis on XWiki Platform, a generic wiki platform. Starting with version 5.3-milestone-2 and prior to versions 13.10.6 and 14.4, it's possible to inject arbitrary wiki syntax including Groovy, Python and Velocity script macros via the request (URL parameter) using the XWikiServerClassSheet if the user has view access to this sheet and another page that has been saved with programming rights, a standard condition on a public read-only XWiki installation or a private XWiki installation where the user has an account. This allows arbitrary Groovy/Python/Velocity code execution which allows bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. Also, this could be used to impact the availability of the wiki. This has been patched in versions 13.10.6 and 14.4. As a workaround, edit the affected document XWiki.XWikiServerClassSheet or WikiManager.XWikiServerClassSheet and manually perform the changes from the patch fixing the issue. On XWiki versions 12.0 and later, it is also possible to import the document XWiki.XWikiServerClassSheet from the xwiki-platform-wiki-ui-mainwiki package version 14.4 using the import feature of the administration application as there have been no other changes to this document since XWiki 12.0.

XWiki Platform Applications Tag and XWiki Platform Tag UI are tag applications for XWiki, a generic wiki platform. Starting with version 1.7 in XWiki Platform Applications Tag and prior to 13.10.6 and 14.4 in XWiki Platform Tag UI, the tags document Main.Tags in XWiki didn't sanitize user inputs properly. This allowed users with view rights on the document (default in a public wiki or for authenticated users on private wikis) to execute arbitrary Groovy, Python and Velocity code with programming rights. This also allowed bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. The vulnerability could be used to impact the availability of the wiki. On XWiki versions before 13.10.4 and 14.2, this can be combined with CVE-2022-36092, meaning that no rights are required to perform the attack. The vulnerability has been patched in versions 13.10.6 and 14.4. As a workaround, the patch that fixes the issue can be manually applied to the document Main.Tags or the updated version of that document can be imported from version 14.4 of xwiki-platform-tag-ui using the import feature in the administration UI on XWiki 10.9 and later.

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

In getdocument.vm ; the ordering of the returned documents is defined from an unsanitized request parameter (request.sort) and can allow any user to inject HQL.

Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries.

It's possible to employ database backend dependent techniques of breaking out of HQL query context, described, for example, here: https://www.sonarsource.com/blog/exploiting-hibernate-injections.

Patches

This has been patched in 13.10.5 and 14.3-rc-1.

Workarounds

There is no known workaround, other than upgrading XWiki.

References

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

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 XWiki Crypto API will generate X509 certificates signed by default using SHA1 with RSA, which is not considered safe anymore for use in certificate signatures, due to the risk of collisions with SHA1. Note that this API is never used in XWiki Standard but it might be used in some extensions of XWiki.

Patches The problem has been patched in XWiki version 13.10.6, 14.3.1 and 14.4-rc-1. Since then, the Crypto API will generate X509 certificates signed by default using SHA256 with RSA.

Workarounds Administrators are advised to upgrade their XWiki installation to one of the patched versions. If the upgrade is not possible, it is possible to patch the module xwiki-platform-crypto in a local installation by applying the change exposed in https://github.com/xwiki/xwiki-platform/commit/26728f3f23658288683667a5182a916c7ecefc52 and re-compiling the module.

References https://jira.xwiki.org/browse/XWIKI-19676 https://github.com/openssl/openssl/blob/master/CHANGES.md?plain=1#L938 https://github.com/openssl/openssl/issues/16650

For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki Email us at security ML

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

The XWiki Platform Index UI is an Index of all pages, attachments, orphans and deleted pages and attachments for XWiki Platform, a generic wiki platform. Prior to versions 13.10.6 and 14.3, it's possible to store JavaScript which will be executed by anyone viewing the deleted attachments index with an attachment containing javascript in its name. This issue has been patched in XWiki 13.10.6 and 14.3. As a workaround, modify fix the vulnerability by editing the wiki page XWiki.DeletedAttachments with the object editor, open the JavaScriptExtension object and apply on the content the changes that can be found on the fix commit.

XWiki Platform Web Parent POM contains Web resources for the XWiki platform, a generic wiki platform. Starting with version 1.0 and prior to versions 13.10.6 and 14.30-rc-1, it's possible to store JavaScript which will be executed by anyone viewing the history of an attachment containing javascript in its name. This issue has been patched in XWiki 13.10.6 and 14.3RC1. As a workaround, it is possible to replace viewattachrev.vm, the entry point for this attack, by a patched version from the patch without updating XWiki.

XWiki Platform Mentions UI is a user interface for mentioning users in wiki content for XWiki Platform, a generic wiki platform. Starting in version 12.5-rc-1 and prior to versions 13.10.6 and 14.4, it's possible to store Javascript or groovy scripts in a mention, macro anchor, or reference field. The stored code is executed by anyone visiting the page with the mention. This issue has been patched on XWiki 14.4 and 13.10.6. As a workaround, one may update XWiki.Mentions.MentionsMacro and edit the Macro code field of the XWiki.WikiMacroClass XObject.

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 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 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 the appropriate escaping.

Workarounds The vulnerable template file createinline.vm is part of XWiki's WAR and can be patched by manually applying the changes from the fix.

XWiki Platform Attachment UI provides a macro to easily upload and select attachments for XWiki Platform, a generic wiki platform. Starting with version 14.0-rc-1 and prior to 14.4-rc-1, it's possible to store JavaScript in an attachment name, which will be executed by anyone trying to move the corresponding attachment. This issue has been patched in XWiki 14.4-rc-1. As a workaround, one may copy moveStep1.vm to webapp/xwiki/templates/moveStep1.vm and replace vulnerable code with code from the patch.

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.

XWiki Platform Old Core is a core package for XWiki Platform, a generic wiki platform. Starting in versions 11.3.7, 11.0.3, and 12.0RC1, it is possible to exploit a bug in XWikiRights resolution of groups to obtain privilege escalation. More specifically, editing a right with the object editor leads to adding a supplementary empty value to groups which is then resolved as a reference to XWiki.WebHome page. Adding an XWikiGroup xobject to that page then transforms it to a group, any user put in that group would then obtain the privileges related to the edited right. Note that this security issue is normally mitigated by the fact that XWiki.WebHome (and XWiki space in general) should be protected by default for edit rights. The problem has been patched in XWiki 13.10.4 and 14.2RC1 to not consider anymore empty values in XWikiRights. It's possible to work around the problem by setting appropriate rights on XWiki.WebHome page to prevent users to edit it.

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