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 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
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 The search administration interface doesn't properly escape the id and label of search user interface extensions, allowing the injection of XWiki syntax containing script macros including Groovy macros that allow remote code execution, impacting the confidentiality, integrity and availability of the whole XWiki instance. This attack can be executed by any user who can edit some wiki page like the user's profile (editable by default) as user interface extensions that will be displayed in the search administration can be added on any document by any user.
To reproduce, edit any document with the object editor, add an object of type XWiki.UIExtensionClass, set "Extension Point Id" to org.xwiki.platform.search, set "Extension ID" to {{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from extension id succeeded!"){{/groovy}}{{/async}}, set "Extension Parameters" to label={{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from label succeeded!"){{/groovy}}{{/async}} and "Extension Scope" to "Current User". Then open the page XWiki.SearchAdmin, e.g., on http://localhost:8080/xwiki/bin/view/XWiki/SearchAdmin. If there are error log messages in XWiki's log that announce that attacks succeeded, the instance is vulnerable.
Patches The necessary escaping has been added in XWiki 14.10.15, 15.5.2 and 15.7RC1.
Workarounds The patch can be manually applied to the page XWiki.SearchAdmin.
References https://github.com/xwiki/xwiki-platform/commit/62863736d78ffd60d822279c5fb7fb9593042766 https://jira.xwiki.org/browse/XWIKI-21200
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 There is a reflected XSS or also direct remote code execution vulnerability in the code for displaying configurable admin sections. The code that can be passed through a URL parameter is only executed when the user who is visiting the crafted URL has edit right on at least one configuration section. While any user of the wiki could easily create such a section, in this case it is much more convenient to exploit GHSA-qj86-p74r-7wp5 which is why this attack scenario won't be further considered in the following. In contrast to GHSA-qj86-p74r-7wp5, this vulnerability doesn't require the attacker to have an account or any access on the wiki. It is sufficient to trick any admin user of the XWiki installation to visit the crafted URL. Alternatively, the URL can also be embedded as image source of an image in any content of the wiki like a comment that could be left by an anonymous user. This vulnerability allows full remote code execution with programming rights and thus impacts the confidentiality, integrity and availability of the whole XWiki installation.
Patches
This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1
Workarounds
The patch can be manually applied to the document XWiki.ConfigurableClass.
References
https://github.com/xwiki/xwiki-platform/commit/5e14c8d08fd0c5b619833d35090b470aa4cb52b0 https://jira.xwiki.org/browse/XWIKI-21167
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 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 Is it possible for a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript. This requires social engineer to trick a user to follow the URL.
Reproduction steps
1. As a user without script or programming right, create a (non-terminal) document named " + alert(1) + " (the quotes need to be part of the name). 1. Edit the class. 1. Add a string property named "test". 1. Edit using the object editor and add an object of the created class 1. Get an admin to open <xwiki-server>/xwiki/bin/view/%22%20%2B%20alert(1)%20%2B%20%22/?viewer=display&type=object&property=%22%20%2B%20alert(1)%20%2B%20%22.WebHome.test&mode=edit where <xwiki-server> is the URL of your XWiki installation.
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-21810 - https://github.com/xwiki/xwiki-platform/commit/27eca8423fc1ad177518077a733076821268509c
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
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
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 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 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
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 The Solr-based search in XWiki discloses the email addresses of users even when obfuscation of email addresses is enabled. To demonstrate the vulnerability, search for objcontent:email using XWiki's regular search interface.
Patches This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1 by not indexing email address properties when obfuscation is enabled. Further, changing the setting now triggers re-indexing of the affected wiki(s).
Workarounds We're not aware of any workarounds.
References https://jira.xwiki.org/browse/XWIKI-20371 https://github.com/xwiki/xwiki-platform/commit/3e5272f2ef0dff06a8f4db10afd1949b2f9e6eea
Attribution This vulnerability was reported on Intigriti by ynoof @Ynoof5.
Impact
When a user has edit but not view right on a page in XWiki, that user can delete the page and replace it by a page with new content without having delete right. The previous version of the page is moved into the recycle bin and can be restored from there by an admin. As the user is recorded as deleter, the user would in theory also be able to view the deleted content, but this is not directly possible as rights of the previous version are transferred to the new page and thus the user still doesn't have view right on the page. From all we examined, it therefore doesn't seem to be possible to exploit this to gain any rights.
To reproduce, just replace view by edit in the URL of a page that you cannot view but edit and save. This should send the page to the recycle bin and replace it by an empty one if the XWiki installation is vulnerable. After the fix, an error is displayed when saving.
Patches This has been patched in XWiki 14.10.21, 15.5.5 and 15.10.6 by cancelling save operations by users when a new document shall be saved despite the document's existing already.
Workarounds We're not aware of any workarounds.
References https://jira.xwiki.org/browse/XWIKI-21553 https://github.com/xwiki/xwiki-platform/commit/c5efc1e519e710afdf3c5f40c0fcc300ad77149f