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
Anyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance.
The easiest way to reproduce this is to edit any document with the object editor and add an object of type XWiki.ConfigurableClass ("Custom configurable sections"). Set "Display in section" and "Display in Category" to "other", set scope to "Wiki and all spaces" and "Heading" to {{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"); println("Hello from Groovy!"){{/groovy}}{{/async}}. Click "Save". Open <xwiki-host>/xwiki/bin/view/Main/?sheet=XWiki.AdminSheet&viewer=content&editor=globaladmin§ion=other where <xwiki-host> is the URL of your XWiki installation. If this displays just "Hello from Groovy!" in a heading and generates an error message with content "Attack from Heading succeeded!" in XWiki's log, the attack succeeded. Similar attacks are also possible by creating this kind of object on a document with a specially crafted name, see the referenced Jira issues for more reproduction steps.
Patches This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1
Workarounds
It is possible to manually apply the fixes for the vulnerability by editing two pages in the wiki. This patch needs to be applied to the page XWiki.ConfigurableClassMacros. Further, the following patches need to be applied to the page XWiki.ConfigurableClass:
https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e#diff-bf419a99140f3c12fd78ea30f855b63cfb74c1c976ff4436898266d9b37ad3ce https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7#diff-bf419a99140f3c12fd78ea30f855b63cfb74c1c976ff4436898266d9b37ad3ce https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6
Note that also the page XWiki.ConfigurableClass needs to be changed to xwiki/2.1 syntax for the escaping to work properly but the security vulnerability is fixed also without changing the syntax.
References
https://github.com/xwiki/xwiki-platform/commit/bd82be936c21b65dee367d558e3050b9b6995713 https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7 https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6 https://jira.xwiki.org/browse/XWIKI-21122 https://jira.xwiki.org/browse/XWIKI-21121 https://jira.xwiki.org/browse/XWIKI-21194
Impact When the realtime editor is installed in XWiki, it allows arbitrary remote code execution with the interaction of an admin user with programming right. More precisely, by getting an admin user to either visit a crafted URL or to view an image with this URL that could be in a comment, the attacker can get the admin to execute arbitrary XWiki syntax including scripting macros with Groovy or Python code. This compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on an XWiki installation, as an admin, click on <xwiki-host>/xwiki/bin/get/RTFrontend/ConvertHTML?wiki=xwiki&space=Main&page=WebHome&text=%7B%7Bvelocity%7D%7D%24logtool.error%28%22Hello%20from%20Velocity%20%21%22%29%7B%7B%2Fvelocity%7D%7D. If the error "Hello from Velocity!" gets logged then the installation is vulnerable.
Patches This vulnerability has been patched in XWiki 14.10.19, 15.5.4 and 15.9.
Workarounds Update RTFrontend.ConvertHTML following this patch. This will, however, break some synchronization processes in the realtime editor, so upgrading should be the preferred way on installations where this editor is used.
References https://jira.xwiki.org/browse/XWIKI-21424 https://github.com/xwiki/xwiki-platform/commit/4896712ee6483da623f131be2e618f1f2b79cb8d
Impact
It's possible for any user knowing the ID of a notification filter preference of another user, to enable/disable it or even delete it. The impact is that the target user might start loosing notifications on some pages because of this. This vulnerability is present in XWiki since 13.2-rc-1.
Patches
The vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0-rc-1. The patch consists in checking properly the rights of the user before performing any action on the filters.
Workarounds
It's possible to fix manually the vulnerability by editing the document XWiki.Notifications.Code.NotificationPreferenceService to apply the changes performed in this commit e8acc9d8e6af7dfbfe70716ded431642ae4a6dd4.
References
JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20337 Commit: e8acc9d8e6af7dfbfe70716ded431642ae4a6dd4
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 @floerer
Impact
It's possible to get access to notification filters of any user by using a URL such as <hostname>xwiki/bin/get/XWiki/Notifications/Code/NotificationFilterPreferenceLivetableResults?outputSyntax=plain&type=custom&user=<username>. This vulnerability impacts all versions of XWiki since 13.2-rc-1. The filters do not provide much information (they mainly contain references which are public data in XWiki), though some info could be used in combination with other vulnerabilities.
Patches
The vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0RC1. The patch consists in checking the rights of the user when sending the data.
Workarounds
It's possible to workaround the vulnerability by applying manually the patch: it's possible for an administrator to edit directly the document XWiki.Notifications.Code.NotificationFilterPreferenceLivetableResults to apply the same changes as in the patch. See c8c6545f9bde6f5aade994aa5b5903a67b5c2582.
References
Jira ticket: https://jira.xwiki.org/browse/XWIKI-20336 Commit: c8c6545f9bde6f5aade994aa5b5903a67b5c2582
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.
Impact When an admin disables a user account, the user's profile is executed with the admin's rights. This allows a user to place malicious code in the user profile before getting an admin to disable the user account.
To reproduce, as a user without script nor programming rights, edit the about section of your user profile and add {{groovy}}services.logging.getLogger("attacker").error("Hello from Groovy!"){{/groovy}}. As an admin, go to the user profile and click the "Disable this account" button. Then, reload the page. If the logs show attacker - Hello from Groovy! then the instance is vulnerable.
Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.
Workarounds We're not aware of any workaround except upgrading.
References https://jira.xwiki.org/browse/XWIKI-21611 https://github.com/xwiki/xwiki-platform/commit/f89c8f47fad6e5cc7e68c69a7e0acde07f5eed5a
Impact It is possible to schedule/trigger/unschedule existing jobs by having an admin visit the Job Scheduler page through a predictable URL, for example by embedding such an URL in any content as an image.
To reproduce in an XWiki installation, open <xwiki-host>:/xwiki/bin/view/Scheduler/?do=trigger&which=Scheduler.NotificationEmailDailySender as a user with admin rights. If there is no error message that indicates the CSRF token is invalid, the installation is vulnerable.
Patches The vulnerability has been fixed on XWiki 14.10.19, 15.5.5, and 15.9.
Workarounds Modify the Scheduler.WebHome page following this patch.
References - https://jira.xwiki.org/browse/XWIKI-20851 - https://github.com/xwiki/xwiki-platform/commit/f16ca4ef1513f84ce2e685d4a05d689bd3a2ab4c
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 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
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 By creating a document with a special crafted documented reference and an XWiki.SchedulerJobClass XObject, it is possible to execute arbitrary code on the server whenever an admin visits the scheduler page or the scheduler page is referenced, e.g., via an image in a comment on a page in the wiki.
To reproduce on an XWiki installation, click on this link to create a new document : <xwiki-host>/xwiki/bin/view/%22%3E%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%20context%3D%22request/parameters%22%7D%7D%7B%7Bvelocity%7D%7D%23evaluate%28%24request/eval%29/. Then, add to this document an object of type XWiki.SchedulerJobClass. Finally, as an admin, go to <xwiki-host>/xwiki/bin/view/Scheduler/?eval=$services.logging.getLogger(%22attacker%22).error(%22Hello%20from%20URL%20Parameter!%20I%20got%20programming:%20$services.security.authorization.hasAccess(%27programming%27)%22). If the logs contain ERROR attacker - 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.
Workarounds Modify the Scheduler.WebHome page following this patch.
References - https://jira.xwiki.org/browse/XWIKI-21416 - https://github.com/xwiki/xwiki-platform/commit/f16ca4ef1513f84ce2e685d4a05d689bd3a2ab4c
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 When uploading an attachment with a malicious filename, malicious JavaScript code could be executed. This requires a social engineering attack to get the victim into uploading a file with a malicious name. The malicious code is solely executed during the upload and affects only the user uploading the attachment. While this allows performing actions in the name of that user, it seems unlikely that a user wouldn't notice the malicious filename while uploading the attachment.
In order to reproduce, as any user, create a file named "><img src=1 onerror=alert(1)>.jpg. Then go to any page where you have edit rights and upload the file in the attachments tab. If alerts appear and display "1", then the instance is vulnerable.
Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.
Workarounds We're not aware of any workaround except upgrading.
References https://jira.xwiki.org/browse/XWIKI-19611 https://jira.xwiki.org/browse/XWIKI-21769 https://jira.xwiki.org/browse/XWIKI-19602 https://github.com/xwiki/xwiki-platform/commit/910a5018a50039e8b24556573dfe342f143ef949
Attribution
This vulnerability has been independently reported by Aleksey Solovev (Positive Technologies) and Georgios Roumeliotis for TwelveSec.
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 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 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
It is possible to access the hash of a password by using the diff feature of the history whenever the object storing the password is deleted. Using that vulnerability it's possible for an attacker to have access to the hash password of a user if they have rights to edit the users' page.
Now with the default right scheme in XWiki this vulnerability is normally prevented on user profiles, except by users with Admin rights. Note that this vulnerability also impacts any extensions that might use passwords stored in xobjects: for those usecases it depends on the right of those pages.
There is currently no way to be 100% sure that this vulnerability has been exploited, as an attacker with enough privilege could have deleted the revision where the xobject was deleted after rolling-back the deletion. But again, this operation requires high privileges on the target page (Admin right). A page with a user password xobject which have in its history a revision where the object has been deleted should be considered at risk and the password should be changed there.
Patches
The vulnerability has been patched in XWiki 14.10.19, 15.5.4 and 15.9-rc-1 by performing a better check before dislaying data of a diff, to ensure it's not coming from a password field.
Workarounds
Admins should ensure that the user pages are properly protected: the edit right shouldn't be allowed for other users than Admin and owner of the profile (which is the default right). Now there's not much workaround possible for a privileged user other than upgrading XWiki.
References
JIRA ticket: https://jira.xwiki.org/browse/XWIKI-19948 Commit: https://github.com/xwiki/xwiki-platform/commit/f1eaec1e512220fabd970d053c627e435a1652cf
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 is vulnerable to reflected cross-site scripting (RXSS) via the rev parameter that is used in the content of the content menu without escaping. If an attacker can convince a user to visit a link with a crafted parameter, this allows the attacker to execute arbitrary actions in the name of the user, including remote code (Groovy) execution in the case of a user with programming right, compromising the confidentiality, integrity and availability of the whole XWiki installation.
The vulnerability can be demonstrated by opening <xwiki-host>/xwiki/bin/view/Main/?rev=xar%3Aorg.xwiki.platform%3Axwiki-platform-distribution-flavor-common%2F15.5%25%25%22%3e%3cscript%3ealert(1)%3c%2fscript%3e where <xwiki-host> is the URL of your XWiki installation. If an alert is displayed, the installation is vulnerable.
Patches This has been patched in XWiki 15.6 RC1, 15.5.1 and 14.10.14.
Workarounds The patch can be manually applied without upgrading (or restarting) the instance.
References https://jira.xwiki.org/browse/XWIKI-21095 https://github.com/xwiki/xwiki-platform/commit/04e325d57d4bcb6ab79bddcafbb19032474c2a55
Attribution
We thank Agostino Parentela, Vulnerability Management Engineer of TicketOne S.p.A., agostino.parentela@ticketone.it for reporting this vulnerability.
Impact XWiki doesn't properly escape the section URL parameter that is used in the code for displaying administration sections. This allows any user with read access to the document XWiki.AdminSheet (by default, everyone including unauthenticated users) to execute code including Groovy code. This impacts the confidentiality, integrity and availability of the whole XWiki instance.
By opening the URL <server>/xwiki/bin/get/Main/WebHome?sheet=XWiki.AdminSheet&viewer=content§ion=%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%7D%7D%7B%7Bgroovy%7D%7Dservices.logging.getLogger(%22attacker%22).error(%22Attack%20succeeded!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D&xpage=view where <server> is the URL of the XWiki installation, it can be tested if an XWiki installation is vulnerable. If this causes a log message ERROR attacker - Attack succeeded! to appear in XWiki's log, the installation is vulnerable. In very old versions of XWiki, the attack can be demonstrated with <server>/xwiki/bin/get/XWiki/XWikiPreferences?section=%3C%25println(%22Hello%20from%20Groovy%22)%25%3E&xpage=view which displays admin.hello from groovy as title when the attack succeeds (tested on XWiki 1.7).
Patches This vulnerability has been patched in XWiki 14.10.14, 15.6 RC1 and 15.5.1.
Workarounds The fix, which consists of replacing = $services.localization.render("administration.sectionTitle$level", [$sectionName]) = by = $services.localization.render("administration.sectionTitle$level", 'xwiki/2.1', [$sectionName]) =, can be applied manually to the document XWiki.AdminSheet.
References https://jira.xwiki.org/browse/XWIKI-21110 https://github.com/xwiki/xwiki-platform/commit/fec8e0e53f9fa2c3f1e568cc15b0e972727c803a
Impact
In XWiki Platform, it's possible to execute content with the right of any user if you can make this user follow a crafted URL. This is possible because edit action sets and thereby executes the page content without checking for a cross-site request forgert (CSRF) token.
To reproduce: Get a user with programming rights to visit the URL <xwiki-host>/xwiki/bin/edit/Main/?content=%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D&xpage=view, where <xwiki-host> is the URL of your XWiki installation. This can be done by embedding an image with this URL.
The text "Hello from Groovy!" is displayed in the page content, showing that the Groovy macro has been executed.
Patches
This has been patched in XWiki 14.10.7 and 15.2-RC-1.
Workarounds There are no known workarounds for it.
References
https://jira.xwiki.org/browse/XWIKI-20386 https://github.com/xwiki/xwiki-platform/commit/cf8eb861998ea423c3645d2e5e974420b0e882be
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 XWiki Platform, it's possible for a user to write a script in which any velocity content is executed with the right of any other document content author.
To reproduce:
As a user with script but not programming right, create a document with the following content:
{{velocity}} #set($main = $xwiki.getDocument('AppWithinMinutes.DynamicMessageTool')) $main.setTitle('$doc.getDocument().getContentAuthor()') $main.getPlainTitle() {{/velocity}}
Since this API require programming right and the user does not have it, the expected result is $doc.document.authors.contentAuthor (not executed script), unfortunately with the security vulnerability we get XWiki.superadmin which shows that the title was executed with the right of the unmodified document.
Patches
This has been patched in XWiki 14.10.7 and 15.2-RC-1.
Workarounds
There are no known workarounds for it.
References
https://jira.xwiki.org/browse/XWIKI-20624 https://github.com/xwiki/xwiki-platform/commit/11a9170dfe63e59f4066db67f84dbfce4ed619c6 https://jira.xwiki.org/browse/XWIKI-20625 https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3
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 XWiki Platform, it's possible for a user to execute any content with the right of an existing document's content author, provided the user have edit right on it. The reason for this is that the edit action sets the content without modifying the content author.
To reproduce: Log in as a user without programming or script right. Open the URL <xwiki-host>/xwiki/bin/edit/<document>/?content=%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D&xpage=view, where <xwiki-host> is the URL of your XWiki installation and <document> is the path to a document whose content author has programming right (or script right) and on which the current user has edit right.
The text "Hello from Groovy!" is displayed in the page content, showing that the Groovy macro has been executed, which should not be the case for a user without programming right.
Patches
This has been patched in XWiki 14.10.6 and 15.2RC1.
Workarounds
There are no known workarounds for it.
References
https://jira.xwiki.org/browse/XWIKI-20385 https://github.com/xwiki/xwiki-platform/commit/a0e6ca083b36be6f183b9af33ae735c1e02010f4
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 view Invitation.WebHome 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. This can be reproduced with the following steps:
1. Open the invitation application (Invitation.WebHome). 1. Set the subject to {{cache}}{{groovy}}new File("/tmp/exploit.txt").withWriter { out -> out.println("Attacked from invitation!"); }{{/groovy}}{{/cache}} 1. Click "Preview"
Patches The vulnerability has been patched on XWiki 14.4.8, 15.2-rc-1, and 14.10.6.
Workarounds The vulnerability can be patched manually by applying the patch on Invitation.InvitationCommon and Invitation.InvitationConfig.
References - https://jira.xwiki.org/browse/XWIKI-20421 - https://github.com/xwiki/xwiki-platform/commit/ff1d8a1790c6ee534c6a4478360a06efeb2d3591
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 Solr-based search in XWiki discloses the password hashes of all users to anyone with view right on the respective user profiles. By default, all user profiles are public. To reproduce, it is sufficient to search for propertyvalue:? AND reference:.password and then deselect the "Document" property under "Result type" in the "Refine your search" widget at the right of the search results. If this displays any passwords or password hashes, the installation is vulnerable.
By default, passwords in XWiki are salted and hashed with SHA-512. On XWiki versions affected by CVE-2022-41933, passwords are stored in plain text if they have been set using the password reset feature. This might affect XWiki installations that are using an external authentication mechanism such that passwords aren't stored in the wiki.
This vulnerability also affects any configurations used by extensions that contain passwords like API keys that are viewable for the attacker. Normally, such passwords aren't accessible but this vulnerability would disclose them as plain text.
Patches This has been patched in XWiki 14.10.15, 15.5.2 and 15.7RC1. This vulnerability has been patched as part of patching GHSA-2grh-gr37-2283, the part of the fix that changes the indexing of single properties to use the same code as the main document for getting the property's value fixes this vulnerability.
Workarounds We're not aware of any workarounds apart from upgrading to a fixed version.
References https://github.com/xwiki/xwiki-platform/commit/3e5272f2ef0dff06a8f4db10afd1949b2f9e6eea https://jira.xwiki.org/browse/XWIKI-21208
Impact
XWiki supports scheduled jobs that contain Groovy scripts. Currently, the job checks the content author of the job for programming right. However, modifying or adding a job script to a document doesn't modify the content author. Together with a CSRF vulnerability in the job scheduler, this can be exploited for remote code execution by an attacker with edit right on the wiki.
For successful exploitation, the needs to have edit right on a document whose content has last been changed by a user with programming right. This could be the user profile for users created by admins. In this document, the attacker can create an object of class XWiki.SchedulerJobClass using the object editor. By setting job class to com.xpn.xwiki.plugin.scheduler.GroovyJob, cron expression to 0 0/5 ? and job script to services.logging.getLogger("foo").error("Job content executed"), the attacker can create a job. Now this job just needs to be triggered or scheduled. This can be achieved by embedding an image with the following XWiki syntax in any document that is visited by an admin: [[image:path:/xwiki/bin/view/Scheduler/?do=trigger&which=Attacker.Document]] where Attacker.Document is the document that has been prepared by the attacker. If the attack is successful, an error log entry with "Job content executed" will be produced.
Patches This vulnerability has been patched in XWiki 14.10.9 and 15.4RC1.
Workarounds There is no workaround.
References https://jira.xwiki.org/browse/XWIKI-20852 https://github.com/xwiki/xwiki-platform/commit/fcdcfed3fe2e8a3cad66ae0610795a2d58ab9662
Impact
Any registered user can use the content field of their user profile page to execute arbitrary scripts with programming rights, thus effectively performing rights escalation.
The problem is present since version 4.3M2 when AppWithinMinutes Application added support for the Content field, allowing any wiki page (including the user profile page) to use its content as an AWM Content field, which has a custom displayer that executes the content with the rights of the AppWithinMinutes.Content author, rather than the rights of the content author.
Patches
The issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262 . The fix is in the content of the AppWithinMinutes.Content page that defines the custom displayer. By using the display script service to render the content we make sure that the proper author is used for access rights checks.
Workarounds
If you want to fix this problem on older versions of XWiki that have not been patched then you need to modify the content of AppWithinMinutes.Content page to use the display script service to render the content, like this:
- {{html}}$tdoc.getRenderedContent($tdoc.content, $tdoc.syntax.toIdString()).replace('{{', '&#123;&#123;'){{/html}} + {{html}}$services.display.content($tdoc, { + 'displayerHint': 'default' + }).replace('{{/html}}', '&#123;&#123;/html&#125;&#125;'){{/html}}
References
JIRA issue https://jira.xwiki.org/browse/XWIKI-19906 Fix https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262
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 found and reported by @michitux .
Impact
Any registered user can exploit a stored XSS through their user profile by setting the payload as the value of the time zone user preference. Even though the time zone is selected from a drop down (no free text value) it can still be set from JavaScript (using the browser developer tools) or by calling the save URL on the user profile with the right query string. Once the time zone is set it is displayed without escaping which means the payload gets executed for any user that visits the malicious user profile, allowing the attacker to steal information and even gain more access rights (escalation to programming rights).
The problem is present since version 4.1M2 when the time zone user preference was introduced.
Patches
The issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/d11ca5d781f8a42a85bc98eb82306c1431e764d4 . The main fix is in the displayertimezone.vm precisely at this line:
$!escapetool.xml($value)
By escaping the displayed time zone value we make sure the attacker's payload is not executed.
Workarounds
If you want to fix this problem on older versions of XWiki that have not been patched then you need to edit displayertimezone.vm and escape the displayed time zone value here:
- $!value + $!escapetool.xml($value)
References
JIRA issue https://jira.xwiki.org/browse/XWIKI-20276 Fix https://github.com/xwiki/xwiki-platform/commit/d11ca5d781f8a42a85bc98eb82306c1431e764d4
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 found and reported by @michitux .
Impact The create action is vulnerable to a CSRF attack, allowing script and thus remote code execution when targeting a user with script/programming right, thus compromising the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, the XWiki syntax [[image:path:/xwiki/bin/create/Foo/WebHome?template=&parent=Main.WebHome&title=$services.logging.getLogger(%22foo%22).error(%22Script%20executed!%22)]] can be added to any place that supports XWiki syntax like a comment. When a user with script right views this image and a log message ERROR foo - Script executed! appears in the log, the XWiki installation is vulnerable.
Patches This has been patched in XWiki 14.10.9 and 15.4RC1 by requiring a CSRF token for the actual page creation.
Workarounds There are no known workarounds.
References https://jira.xwiki.org/browse/XWIKI-20849 https://github.com/xwiki/xwiki-platform/commit/4b20528808d0c311290b0d9ab2cfc44063380ef7
Impact It is possible in XWiki to execute Velocity code without having script right by creating an XClass with a property of type "TextArea" and content type "VelocityCode" or "VelocityWiki". For the former, the syntax of the document needs to be set the xwiki/1.0 (this syntax doesn't need to be installed). In both cases, when adding the property to an object, the Velocity code is executed regardless of the rights of the author of the property (edit right is still required, though). In both cases, the code is executed with the correct context author so no privileged APIs can be accessed. However, Velocity still grants access to otherwise inaccessible data and APIs that could allow further privilege escalation.
At least for "VelocityCode", this behavior is most likely very old but only since XWiki 7.2, script right is a separate right, before that version all users were allowed to execute Velocity and thus this was expected and not a security issue.
Patches This has been patched in XWiki 14.10.10 and 15.4 RC1.
Workarounds There are no known workarounds.
References https://jira.xwiki.org/browse/XWIKI-20847 https://jira.xwiki.org/browse/XWIKI-20848 https://github.com/xwiki/xwiki-platform/commit/edc52579eeaab1b4514785c134044671a1ecd839
Impact
Triggering the office converter with a specially crafted file name allows writing the attachment's content to an attacker-controlled location on the server as long as the Java process has write access to that location. In particular in the combination with attachment moving, a feature introduced in XWiki 14.0, this is easy to reproduce but it also possible to reproduce in versions as old as XWiki 3.5 by uploading the attachment through the REST API which doesn't remove / or \ from the filename. As the mime type of the attachment doesn't matter for the exploitation, this could e.g., be used to replace the jar-file of an extension which would allow executing arbitrary Java code and thus impact the confidentiality, integrity and availability of the XWiki installation. To reproduce the issue on versions since XWiki 14.0, execute the following steps:
1. Activate the office server 2. Upload an arbitrary file with the extension .doc, e.g., to your user profile (you can use a regular plain text file, only the extension matters). 3. Use the attachment move feature to rename the file to ../../../../../tmp/Hello from XWiki.txt where the latter part is the location of a file you want to write on the server. The number of ../ depends on the directory depth, the provided example should work on Linux with the demo distribution. 4. Click the "preview" link to trigger the office converter
For information how to reproduce on older versions, see the Jira issue.
To the best of our knowledge, this attack is not possible when the office conversion process doesn't run as the code fails before the file is written.
Patches
This vulnerability has been patched in XWiki 14.10.8 and 15.3RC1.
Workarounds
There are no known workarounds apart from disabling the office converter.
References
https://jira.xwiki.org/browse/XWIKI-20715 https://github.com/xwiki/xwiki-platform/commit/45d182a4141ff22f3ff289cf71e4669bdc714544