XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions it's possible for an unprivileged user to perform a remote code execution by injecting a groovy script in her own profile and by calling the Reset password feature since the feature is performing a save of the user profile with programming rights in the impacted versions of XWiki. The issue has been patched in XWiki 13.1RC1. There are two different possible workarounds, each consisting of modifying the XWiki/ResetPassword page. 1. The Reset password feature can be entirely disabled by deleting the XWiki/ResetPassword page. 2. The script in XWiki/ResetPassword can also be modified or removed: an administrator can replace it with a simple email contact to ask an administrator to reset the password.

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.

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 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 trying to create a document that already exists, XWiki displays an error message in the form for creating it. Due to missing escaping, this error message is vulnerable to raw HTML injection and thus XSS. The injected code is the document reference of the existing document so this requires that the attacker first creates a non-empty document whose name contains the attack code.

To reproduce, the following steps can be used:

1. Go to <xwiki-host>/xwiki/bin/create/Main/WebHome?parent=&templateprovider=&spaceReference=&name=%3Cimg%20onerror=%22alert(1)%22%20src=%22test%22 where <xwiki-host> is the URL of your XWiki installation. 2. Create the page and add some content. 3. Go again to <xwiki-host>/xwiki/bin/create/Main/WebHome?parent=&templateprovider=&spaceReference=&name=%3Cimg%20onerror=%22alert(1)%22%20src=%22test%22 where <xwiki-host> is the URL of your XWiki installation.

If an alert with content "1" is displayed, the installation is vulnerable. This allows an attacker to execute arbitrary actions with the rights of the user opening the malicious link. Depending on the rights of the user, this may allow remote code execution and full read and write access to the whole XWiki installation.

Patches This has been patched in XWiki 14.10.12 and 15.5RC1 by adding the appropriate escaping.

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

Impact An attacker can create a template provider on any document that is part of the wiki (could be the attacker's user profile) that contains malicious code. This code is executed when this template provider is selected during document creation which can be triggered by sending the user to a URL. For the attacker, the only requirement is to have an account as by default the own user profile is editable. This allows an attacker to execute arbitrary actions with the rights of the user opening the malicious link. Depending on the rights of the user, this may allow remote code execution and full read and write access to the whole XWiki installation.

For reproduction, the following steps can be used: 1. As a simple user with no script right, edit the user profile with the object editor and add an object of type "Template Provider Class". Set the name to "My Template", set template to any page on the wiki. In "Creation Restrictions", enter <img onerror="alert(1)" src="https://www.example.com". Accept the suggestion to add this string in the dropdown. Click "Save & View" 2. As any user with edit right, open <xwiki-host>/xwiki/bin/create/Main/WebHome?parent=&templateprovider=XWiki.<username>&name=foo&spaceReference=Bar, where <xwiki-host> is the URL of your XWiki installation and <username> is the username of the attacker.

If an alert is displayed, the installation is vulnerable.

Patches This has been patched in XWiki 14.10.12 and 15.5RC1 by adding the appropriate escaping.

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

References https://github.com/xwiki/xwiki-platform/commit/ba56fda175156dd35035f2b8c86cbd8ef1f90c2e https://jira.xwiki.org/browse/XWIKI-20962