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 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. 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 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 is a generic wiki platform. Starting in version 6.0, users with write rights can insert well-formed content that is not handled well by the parser. As a consequence, some pages becomes unusable, including the user index (if the page containing the faulty content is a user page) and the page index.
Note that on the page, the normal UI is completely missing and it is not possible to open the editor directly to revert the change as the stack overflow is already triggered while getting the title of the document. This means that it is quite difficult to remove this content once inserted.
This has been patched in XWiki 13.10.10, 14.4.6, and 14.9-rc-1. A temporary workaround to avoid Stack Overflow errors is to increase the memory allocated to the stack by using the -Xss JVM parameter (e.g., -Xss32m). This should allow the parser to pass and to fix the faulty content. The consequences for other aspects of the system (e.g., performance) are unknown, and this workaround should be only be used as a temporary solution. The workaround does not prevent the issue occurring again with other content. Consequently, it is strongly advised to upgrade to a version where the issue has been patched.
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.
XWiki Platform is a generic wiki platform. Starting in version 1.3-rc-1, any user with edit right can execute arbitrary database select and access data stored in the database. The problem has been patched in XWiki 13.10.11, 14.4.7, and 14.10. There is no workaround for this vulnerability other than upgrading.
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 3.0-milestone-1, it's possible to execute a script with the right of another user, provided the target user does not have programming right. The problem has been patched in XWiki 14.8-rc-1, 14.4.5, and 13.10.10. There are no known workarounds for this issue.
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. 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 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 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.
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.
XWiki Commons are technical libraries common to several other top level XWiki projects. It's possible to list some users who are normally not viewable from subwiki by requesting users on a subwiki which allows only global users with uorgsuggest.vm. This issue only concerns hidden users from main wiki. Note that the disclosed information are the username and the first and last name of users, no other information is leaked. The problem has been patched on XWiki 13.10.8, 14.4.3 and 14.7RC1.
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
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 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.
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.
XWiki Commons are technical libraries common to several other top level XWiki projects. It is possible to bypass the existing security measures put in place to avoid open redirect by using a redirect such as //mydomain.com (i.e. omitting the http:). It was also possible to bypass it when using URL such as http:/mydomain.com. The problem has been patched on XWiki 13.10.10, 14.4.4 and 14.8RC1.
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
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 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
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
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
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
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 exploit the same vulnerability to perform internal requests: https://jira.xwiki.org/browse/XWIKI-20449
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