Impact XWiki is vulnerable to a remote code execution (RCE) attack through its user registration feature. This issue allows an attacker to execute arbitrary code by crafting malicious payloads in the "first name" or "last name" fields during user registration. This impacts all installations that have user registration enabled for guests.

To reproduce, register with any username and password and the following payload as "first name": ]]{{/html}}{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack succeeded){{/groovy}}{{/async}}. In the following page that confirms the success of the registration, the full first name should be displayed, linking to the created user. If the formatting is broken and a log message with content "ERROR attacker - Attack succeeded!" is logged, the attack succeeded.

Patches This vulnerability has been patched in XWiki 14.10.17, 15.5.3 and 15.8 RC1.

Workarounds

In the administration of your wiki, under "Users & Rights" > "Registration" set the "Registration Successful Message" to the following code:

velocity #set($message = $services.localization.render('core.register.successful', 'xwiki/2.1', ['USERLINK', $userName])) #set($userLink = $xwiki.getUserName("$userSpace$userName")) {{info}}$message.replace('USERLINK', "{{html clean=false}}$userLink{{/html}}"){{/info}}

References https://jira.xwiki.org/browse/XWIKI-21173 https://github.com/xwiki/xwiki-platform/commit/b290bfd573c6f7db6cc15a88dd4111d9fcad0d31

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

Impact

The default macro content parser didn't preserve the restricted attribute of the transformation context when executing nested macros. This allows executing macros that are normally forbidden in restricted mode, in particular script macros. The cache and chart macros that are bundled in XWiki use the vulnerable feature. The following XWiki syntax, when used inside a comment in XWiki, demonstrates the privilege escalation from comment right to programming right and thus remote code execution (RCE) that is possible due to this:

{{cache}}{{groovy}}println("Hello from Groovy!"){{/groovy}}{{/cache}}

This vulnerability exists since the restricted attribute has been added to the transformation context in version 4.2.

Patches This has been patched in XWiki 13.10.11, 14.4.7 and 14.10.

Workarounds To avoid the exploitation of this bug, comments can be disabled for untrusted users until an upgrade to a patched version has been performed. Note that users with edit rights will still be able to add comments via the object editor even if comments have been disabled.

Resources https://github.com/xwiki/xwiki-rendering/commit/c73fa3ccd4ac59057e48e5d4325f659e78e8f86d https://jira.xwiki.org/browse/XRENDERING-689 https://jira.xwiki.org/browse/XWIKI-20375

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 René de Sain @renniepak.

XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Starting in version 1.0 and prior to version 1.26.5, missing escaping of the width parameter in the column macro allows remote code execution for any user who can edit any page or who can access the CKEditor converter. The width parameter is used without escaping in XWiki syntax, thus allowing XWiki syntax injection which enables remote code execution when the macro has been installed by a user with programming right, or it at least allows executing Velocity code as the wiki admin. Version 1.26.5 contains a patch for the issue.

XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Starting in version 1.0 and prior to version 1.26.5, missing escaping of the classes parameter in the panel macro allows remote code execution for any user who can edit any page The classes parameter is used without escaping in XWiki syntax, thus allowing XWiki syntax injection which enables remote code execution. Version 1.26.5 contains a patch for the issue.

XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Starting in version 1.0 and prior to version 1.26.5, missing escaping of the ac:type in the ConfluenceLayoutSection macro allows remote code execution for any user who can edit any page The classes parameter is used without escaping in XWiki syntax, thus allowing XWiki syntax injection which enables remote code execution. Version 1.26.5 has a fix for the issue.

XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Starting in version 1.0 and prior to version 1.26.5, missing escaping of the title in the confluence paste code macro allows remote code execution for any user who can edit any page. The classes parameter is used without escaping in XWiki syntax, thus allowing XWiki syntax injection which enables remote code execution. Version 1.26.5 has a fix for the issue.

Impact

Anyone who has view rights on the Calendar.JSONService page, including guest users can exploit this vulnerability by accessing database info or starting a DoS attack.

Workarounds

Remove the Calendar.JSONService page. This will however break some functionalities.

References

Jira issue: FULLCAL-80: SQL injection through Calendar.JSONService FULLCAL-81: SQL injection through Calendar.JSONService still exists

For more information

If there are any questions or comments about this advisory: Open an issue in Jira XWiki.org Email Security Mailing List

Impact

It's possible for a user without any specific right to perform script injection and remote code execution just by inserting an appropriate title when creating a new Change Request. This vulnerability is particularly critical as Change Request aims at being created by user without any particular rights.

Patches

The vulnerability has been fixed in Change Request 1.9.2.

Workarounds

It's possible to workaround the issue without upgrading by editing the document ChangeRequest.Code.ChangeRequestSheet and by performing the same change as in the commit: https://github.com/xwiki-contrib/application-changerequest/commit/7565e720117f73102f5a276239eabfe85e15cff4.

References

JIRA ticket: https://jira.xwiki.org/browse/CRAPP-298 Commit of the fix: https://github.com/xwiki-contrib/application-changerequest/commit/7565e720117f73102f5a276239eabfe85e15cff4

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

Thanks Michael Hamann for the report.

Impact

When login via the OAuth method, the identityOAuth parameters, sent in a GET request is vulnerable to XSS and XWiki syntax injection. This allows remote code execution via the groovy macro and thus affects the confidentiality, integrity and availability of the whole XWiki installation.

The vulnerability is in this part of the code.

Patches The issue has been fixed in Identity OAuth version 1.6 by https://github.com/xwikisas/identity-oauth/commit/d805d3154b17c6bf455ddf5deb0a3461a3833bc6 . The fix is in the content of the IdentityOAuth/LoginUIExtension file

Workarounds There are no known workarounds besides upgrading.

References Are there any links users can visit to find out more?

Original report: https://jira.xwiki.org/browse/XWIKI-20719

Impact

Improper escaping in the document SkinsCode.XWikiSkinsSheet leads to a possible privilege escalation from view right on that document to programming rights, or in other words, it is possible to execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents.

The attack works by opening a non-existing page with a name crafted to contain a dangerous payload.

It is possible to check if an existing installation is vulnerable by opening <xwiki-host>/xwiki/bin/view/%22%5D%5D%20%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22Hello%20%22%20%2B%20%22from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D?sheet=SkinsCode.XWikiSkinsSheet&xpage=view where <xwiki-host is the URL of the XWiki installation. The expected result are two list items with "Edit this skin" and "Test this skin" without any further text. If the installation is vulnerable, the second list item is "Test this skin Hello from groovy!.WebHome"]]". This shows that the Groovy macro has been executed.

Patches

This has been patched in XWiki 14.4.8, 14.10.4 and 15.0-rc-1.

Workarounds

The fix can also be applied manually to the impacted document SkinsCode.XWikiSkinsSheet.

References

https://jira.xwiki.org/browse/XWIKI-20457 https://github.com/xwiki/xwiki-platform/commit/d9c88ddc4c0c78fa534bd33237e95dea66003d29

For more information

If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List

XWiki Platform is a generic wiki platform. 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.