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
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
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 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
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 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
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 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 When document names are validated according to a name strategy (disabled by default), XWiki is vulnerable to a reflected XSS attack in the page creation form. To reproduce, make sure that "Validate names before saving" is enabled in the administration under "Editing" -> "Name strategies" and then open <xwiki-host>/xwiki/bin/create/Main/%3Cscript%3Ealert%28%27Test%20Test%20Test%20Test%20Test%27%29%3C%2Fscript%3E where <xwiki-host> is the URL of your XWiki installation. This displays an alert if 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.5-RC-1 by adding 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
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
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 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
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
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 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 In XWiki, it is possible to pass a title to the page creation action that isn't displayed at first but then executed in the second step. This can be used by an attacker to trick a victim to execute code, allowing script execution if the victim has script right or remote code execution including full access to the XWiki instance if the victim has programming right.
For the attack to work, the attacker needs to convince the victim to visit a link like <xwiki-host>/xwiki/bin/create/NonExistingSpace/WebHome?title=$services.logging.getLogger(%22foo%22).error(%22Script%20executed!%22) where <xwiki-host> is the URL of the Wiki installation and to then click on the "Create" button on that page. The page looks like a regular XWiki page that the victim would also see when clicking the button to create a page that doesn't exist yet, the malicious code is not displayed anywhere on that page. After clicking the "Create" button, the malicious title would be displayed but at this point, the code has already been executed and the attacker could use this code also to hide the attack, e.g., by redirecting the victim again to the same page with an innocent title. It thus seems plausible that this attack could work if the attacker can place a fake "create page" button on a page which is possible with edit right.
Patches This has been patched in XWiki 14.10.2 and 15.5RC1 by displaying the title already in the first step such that the victim can notice the attack before continuing.
Workarounds It is possible to manually patch the modified files from the patch in an existing installation. For the JavaScript change, the minified JavaScript file would need to be obtained from a build of XWiki and replaced accordingly.
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
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