Impact By creating a document with a specially crafted title, it is possible to trigger remote code execution in the (Solr-based) search in XWiki. This allows any user who can edit the title of a space (all users by default) to execute any Groovy code in the XWiki installation which compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce, as a user without script nor programming rights, create a document with title {{/html}}{{async}}{{groovy}}println("Hello from Groovy Title!"){{/groovy}}{{/async}} and content Test Document. Using the search UI, search for "Test Document", then deploy the Location facet on the right of the screen, next to the search results. The installation is vulnerable if you see an item such as: Hello from Groovy Title! </a> <div class="itemCount">1</div> </li> </ul> {{/html}}
Patches This has been patched in XWiki 14.10.20, 15.5.4 and 15.10 RC1.
Workarounds Modify the Main.SolrSpaceFacet page following this patch.
References https://jira.xwiki.org/browse/XWIKI-21471 https://github.com/xwiki/xwiki-platform/commit/acba74c149a041345b24dcca52c586f872ba97fb https://github.com/xwiki/xwiki-platform/commit/74e301c481e69eeea674dac7fed6af3614cf08c5
Impact XWiki's database search allows remote code execution through the search text. This allows remote code execution for any visitor of a public wiki or user of a closed wiki as the database search is by default accessible for all users. This impacts the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on an instance, without being logged in, go to <hostname>/xwiki/bin/get/Main/DatabaseSearch?outputSyntax=plain&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello%20from%22%20%2B%20%22%20search%20text%3A%22%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20. If the title of the RSS channel contains Hello from search text:42, the instance is vulnerable.
Patches This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10RC1.
Workarounds It is possible to manually apply this patch to the page Main.DatabaseSearch. Alternatively, unless database search is explicitly used by users, this page can be deleted as this is not the default search interface of XWiki.
References https://jira.xwiki.org/browse/XWIKI-21472 https://github.com/xwiki/xwiki-platform/commit/95bdd6cc6298acdf7f8f21298d40eeb8390a8565
Impact
In multilingual wikis, translations can be edited by any user who has edit right, circumventing the rights that are normally required for authoring translations (script right for user-scope translations, wiki admin for translations on the wiki). This can be exploited for remote code execution if the translation value is not properly escaped where it is used. To reproduce, in a multilingual wiki, as a user without script or admin right, edit a translation of AppWithinMinutes.Translations and in the line platform.appwithinminutes.description= add {{async}}{{groovy}}println("Hello from Translation"){{/groovy}}{{/async}} at the end. Then open the app with in minutes home page (AppWithinMinutes.WebHome) in the same locale. If translations are still working and "Hello from Translation" is displayed at the end of the introduction, the installation is vulnerable.
Patches This has been patched in XWiki 14.10.20, 15.5.4 and 15.10RC1.
Workarounds We're not aware of any workaround except restricting edit right on documents that contain translations.
References https://jira.xwiki.org/browse/XWIKI-21411 https://github.com/xwiki/xwiki-platform/commit/c4c8d61c30de72298d805ccc82df2a307f131c54
Impact Remote code execution is possible via PDF export templates. To reproduce on an installation, register a new user account with username PDFClass if XWiki.PDFClass does not exist. On XWiki.PDFClass, use the class editor to add a "style" property of type "TextArea" and content type "Plain Text". Then, add an object of class PDFClass and set the "style" attribute to $services.logging.getLogger('PDFClass').error("I got programming: $services.security.authorization.hasAccess('programming')"). Finally, go to <host>/xwiki/bin/export/Main/WebHome?format=pdf&pdftemplate=XWiki.PDFClass. If the logs contain "ERROR PDFClass - I got programming: true", the instance is vulnerable.
Patches This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10-rc-1.
Workarounds If PDF templates are not typically used on the instance, an administrator can create the document XWiki.PDFClass and block its edition, after making sure that it does not contain a style attribute. Otherwise, the instance needs to be updated.
References - https://jira.xwiki.org/browse/XWIKI-21337 - https://github.com/xwiki/xwiki-platform/commit/d28e21a670c69880b951e415dd2ddd69d273eae9
Impact The HTML escaping of escaping tool that is used in XWiki doesn't escape {, which, when used in certain places, allows XWiki syntax injection and thereby remote code execution.
To reproduce in an XWiki installation, open <xwiki-host>/xwiki/bin/view/Panels/PanelLayoutUpdate?place=%7B%7B%2Fhtml%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bvelocity%7D%7D%23evaluate(%24request.eval)%7B%7B%2Fvelocity%7D%7D%7B%7B%2Fasync%7D%7D&eval=Hello%20from%20URL%20Parameter!%20I%20got%20programming%3A%20%24services.security.authorization.hasAccess(%27programming%27) where <xwiki-host> is the URL of your XWiki installation. If this displays You are not admin on this place Hello from URL Parameter! I got programming: true, the installation is vulnerable.
Patches The vulnerability has been fixed on XWiki 14.10.19, 15.5.5, and 15.9 RC1.
Workarounds Apart from upgrading, there is no generic workaround. However, replacing $escapetool.html by $escapetool.xml in XWiki documents fixes the vulnerability. In a standard XWiki installation, we're only aware of the document Panels.PanelLayoutUpdate that exposes this vulnerability, patching this document is thus a workaround. Any extension could expose this vulnerability and might thus require patching, too.
References - https://github.com/xwiki/xwiki-commons/commit/b94142e2a66ec32e89eacab67c3da8d91f5ef93a - https://jira.xwiki.org/browse/XCOMMONS-2828 - https://jira.xwiki.org/browse/XWIKI-21438
Impact Any user who can edit any page like their profile can create a custom skin with a template override that is executed with programming right, thus allowing remote code execution.
To reproduce, as a user without edit, script or admin right, add an object of class XWiki.XWikiSkins to your profile. Name it whatever you want and set the Base Skin to flamingo. Add an object of class XWikiSkinFileOverrideClass and set the path to macros.vm and the content to: #macro(mediumUserAvatar $username) #resizedUserAvatar($username 50) $services.logging.getLogger('Skin').error("I got programming: $services.security.authorization.hasAccess('programming')") #end Back to your profile, click Test this skin. Force a refresh, just in case. If the error "Skin - I got programming: true" gets logged, the installation is vulnerable.
Patches This has been patched in XWiki 14.10.19, 15.5.4 and 15.10RC1.
Workarounds We're not aware of any workaround except upgrading.
References https://jira.xwiki.org/browse/XWIKI-21478 https://github.com/xwiki/xwiki-platform/commit/3d4dbb41f52d1a6e39835cfb1695ca6668605a39 (>= 15.8 RC1) https://github.com/xwiki/xwiki-platform/commit/da177c3c972e797d92c1a31e278f946012c41b56 (< 15.8 RC1)
Impact Any user with edit right on any page can execute any code on the server by adding an object of type XWiki.SearchSuggestSourceClass to their user profile or any other page. This compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on an instance, as a user without script nor programming rights, add an object of type XWiki.SearchSuggestSourceClass to your profile page. On this object, set every possible property to }}}{{async}}{{groovy}}println("Hello from Groovy!"){{/groovy}}{{/async}} (i.e., name, engine, service, query, limit and icon). Save and display the page, then append ?sheet=XWiki.SearchSuggestSourceSheet to the URL. If any property displays as Hello from Groovy!}}}, then the instance is vulnerable.
Patches This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10 RC1.
Workarounds This patch can be manually applied to the document XWiki.SearchSuggestSourceSheet.
References https://jira.xwiki.org/browse/XWIKI-21474 https://github.com/xwiki/xwiki-platform/commit/6a7f19f6424036fce3d703413137adde950ae809
Impact Parameters of UI extensions are always interpreted as Velocity code and executed with programming rights. Any user with edit right on any document like the user's own profile can create UI extensions. This allows remote code execution and thereby impacts the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce, edit your user profile with the object editor and add a UIExtension object with the following values: Extension Point ID: org.xwiki.platform.panels.Applications Extension ID: platform.panels.myFakeApplication Extension parameters:Â label=I got programming right: $services.security.authorization.hasAccess('programming') target=Main.WebHome targetQueryString= icon=icon:bomb Extension Scope: "Current User".
Save the document and open any document. If an application entry with the text "I got programming right: true" is displayed, the attack succeeded, if the code in "label" is displayed literally, the XWiki installation isn't vulnerable.
Patches This vulnerability has been patched in XWiki 14.10.19, 15.5.4 and 15.9-RC1.
Workarounds We're not aware of any workarounds apart from upgrading.
References https://jira.xwiki.org/browse/XWIKI-21335 https://github.com/xwiki/xwiki-platform/commit/171e7c7d0e56deaa7b3678657ae26ef95379b1ea
Impact
The content of a document included using {{include reference="targetdocument"/}} is executed with the right of the includer and not with the right of its author.
This means that any user able to modify the target document can impersonate the author of the content which used the include macro.
Patches
This has been patched in XWiki 15.0 RC1 by making the default behavior safe.
Workarounds
Make sure to protect any included document to make sure only allowed users can modify it.
A workaround have been provided in 14.10.2 to allow forcing to execute the included content with the target content author instead of the default behavior. See https://extensions.xwiki.org/xwiki/bin/view/Extension/Include%20Macro#HAuthor for more details.
References
https://jira.xwiki.org/browse/XWIKI-5027 https://jira.xwiki.org/browse/XWIKI-20471
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 right on any page can perform arbitrary remote code execution by adding instances of XWiki.SearchSuggestConfig and XWiki.SearchSuggestSourceClass to their user profile or any other page. This compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on an instance, as a user without script nor programming rights, add an object of type XWiki.SearchSuggestConfig to your profile page, and an object of type XWiki.SearchSuggestSourceClass as well. On this last object, set both name and icon properties to $services.logging.getLogger("attacker").error("I got programming: $services.security.authorization.hasAccess('programming')") and limit and engine to {{/html}}{{async}}{{velocity}}$services.logging.getLogger("attacker").error("I got programming: $services.security.authorization.hasAccess('programming')"){{/velocity}}{{/async}}. Save and display the page. If the logs contain any message ERROR attacker - I got programming: true then the instance is vulnerable.
Patches This vulnerability has been patched in XWiki 14.10.21, 15.5.5 and 15.10.2.
Workarounds We're not aware of any workaround except upgrading.
References - https://jira.xwiki.org/browse/XWIKI-21473 - https://github.com/xwiki/xwiki-platform/commit/742cd4591642be4cdcaf68325f17540e0934e64e
Pro Macros provides XWiki rendering macros. Missing escaping in the Viewpdf macro allows any user with view right on the CKEditor.HTMLConverter page or edit or comment right on any page to perform remote code execution. Other macros like Viewppt are vulnerable to the same kind of attack. This vulnerability is fixed in 1.10.1.
Impact On instances where Extension Repository Application is installed, any user can execute any code requiring programming rights on the server. In order to reproduce on an instance, as a normal user without script nor programming rights, go to your profile and add an object of type ExtensionCode.ExtensionClass. Set the description to {{async}}{{groovy}}println("Hello from Description"){{/groovy}}{{/async}} and press Save and View. If the description displays as Hello from Description without any error, then the instance is vulnerable.
Patches This vulnerability has been fixed in XWiki 15.10.9 and 16.3.0.
Workarounds Since Extension Repository Application is not mandatory, it can be safely disabled on instances that do not use it. It is also possible to manually apply this patch to the page ExtensionCode.ExtensionSheet, as well as this patch to the page ExtensionCode.ExtensionAuthorsDisplayer.
References https://jira.xwiki.org/browse/XWIKI-21890 https://github.com/xwiki/xwiki-platform/commit/8659f17d500522bf33595e402391592a35a162e8
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 an account can perform arbitrary remote code execution by adding instances of XWiki.WikiMacroClass to any page. This compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on a instance, as a connected user without script nor programming rights, go to your user profile and add an object of type XWiki.WikiMacroClass. Set "Macro Id", "Macro Name" and "Macro Code" to any value, "Macro Visibility" to Current User and "Macro Description" to {{async}}{{groovy}}println("Hello from User macro!"){{/groovy}}{{/async}}. Save the page, then go to <host>/xwiki/bin/view/XWiki/XWikiSyntaxMacrosList. If the description of your new macro reads "Hello from User macro!", then your instance is vulnerable.
Patches This vulnerability has been fixed in XWiki 15.10.11, 16.4.1 and 16.5.0.
Workarounds It is possible to manually apply this patch to the page XWiki.XWikiSyntaxMacrosList.
References
https://jira.xwiki.org/browse/XWIKI-22030 https://github.com/xwiki/xwiki-platform/commit/40e1afe001d61eafdf13f3621b4b597a0e58a3e3
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.
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.
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 IncludedDocuments panel. The problem has been patched on XWiki 14.4.7, and 14.10.
XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents 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 documentTree macro parameters in This macro is installed by default in FlamingoThemesCode.WebHome. This page is installed by default. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10.
XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights WikiManager.DeleteWiki 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 wikiId url parameter. The problem has been patched on XWiki 13.10.11, 14.4.7, and 14.10.
XWiki Commons are technical libraries common to several other top level XWiki projects. The HTML macro does not systematically perform a proper neutralization of script-related html tags. As a result, any user able to use the html macro in XWiki, is able to introduce an XSS attack. This can be particularly dangerous since in a standard wiki, any user is able to use the html macro directly in their own user profile page. The problem has been patched in XWiki 14.8RC1. The patch involves the HTML macros and are systematically cleaned up whenever the user does not have the script correct.
XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents including the legacy notification activity macro 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 macro parameters of the legacy notification activity macro. This macro is installed by default in XWiki. The vulnerability can be exploited via every wiki page that is editable including the user's profile, but also with just view rights using the HTMLConverter that is part of the CKEditor integration which is bundled with XWiki. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10.
XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents including the notification preferences macros 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 user parameter of the macro that provide the notification filters. These macros are used in the user profiles and thus installed by default in XWiki. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10.
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/XWIKI-20462
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 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