Impact
It is possible for a remote unauthenticated user to escape from the HQL execution context and perform a blind SQL injection to execute arbitrary SQL statements on the database backend, including when "Prevent unregistered users from viewing pages, regardless of the page rights" and "Prevent unregistered users from editing pages, regardless of the page rights" options are enabled.
Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries.
The vulnerability may be tested in a default installation of XWIki Standard Flavor, including using the official Docker containers.
An example query, which leads to SQL injection with MySQL/MariaDB backend is shown below:
time curl "http://127.0.0.1:8080/rest/wikis/xwiki/query?q=where%20doc.name=length('a')org.apache.logging.log4j.util.Chars.SPACE%20or%201%3C%3E%271%5C%27%27%20union%20select%201,2,3,sleep(10)%20%23%27&type=hql&distinct=0"
When executed, the response from the server will come after a delay of 10 extra seconds, indicating successful execution of the injected SQL statement.
An example of a query for the PostgreSQL database backend is shown below:
curl "https://127.0.0.1:8080/rest/wikis/xwiki/query?q=where%20%24%24='%24%24=concat(%20chr(%2061%20),(chr(%2039%20))%20)%20;select%201%20--%20comment'&type=hql&distinct=0"
Both requests employ database backend dependent techniques of breaking out of HQL query context, described, for example, here: https://www.sonarsource.com/blog/exploiting-hibernate-injections.
Patches
This has been patched in 16.10.1, 16.4.6 and 15.10.16.
Workarounds
There is no known workaround, other than upgrading XWiki.
References
https://jira.xwiki.org/browse/XWIKI-22691
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
Sergey Anufrienko from Kaspersky ICS-CERT vulnerability research team reported this vulnerability.
Impact
It is possible for a user with SCRIPT right to escape from the HQL execution context and perform a blind SQL injection to execute arbitrary SQL statements on the database backend.
Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries.
The vulnerability may be tested in a default installation of XWIki Standard Flavor, including using the official Docker containers.
For example, with a MySQL or MariaDB database, you can use the following script (which a user having SCRIPT right but not PROGRAMMING right) to get the content of the xwikistrings table (which contain all the short string fields stored in objects, including passwords):
{{velocity}} $services.query.hql("where 1<>'1\'' union select concat(XWSNAME, XWSVALUE) from xwikistrings #'").execute() {{/velocity}}
Patches
This has been patched in 16.10.1, 16.4.6 and 15.10.16.
Workarounds
There is no known workaround, other than upgrading XWiki.
The protection added to this REST API is the same as the one used to validate complete select queries, making it more consistent. However, while the script API always had this protection for complete queries, it's important to note that it's a very strict protection and some valid, but complex, queries might suddenly require the author to have programming right.
References
https://jira.xwiki.org/browse/XWIKI-22718
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
This vulnerability impacts users of a subwiki of XWiki where Message Stream is enabled and use, if they configured their wiki to be closed by selecting "Prevent unregistered users to view pages" in the Administrations Rights.
The vulnerability is that any message sent in a subwiki to "everyone" is actually sent to the farm: any visitor of the main wiki will be able to see that message through the Dashboard, even if the subwiki is configured to be private.
Patches
This problem has not been patched and is not going to be patched in the future: Message Stream has been deprecated in XWiki 16.8.0RC1 and is not maintained anymore.
Workarounds
Message Stream is disabled by default, it's advised to keep it disabled from Administration > Social > Message Stream.
References
https://jira.xwiki.org/browse/XWIKI-17154
Impact
NOTE: The Realtime WYSIWYG Editor extension was experimental, and thus not recommended, in the versions affected by this vulnerability. It has become enabled by default, and thus recommended, starting with XWiki 16.9.0.
A user with only edit right can join a realtime editing session where others, that where already there or that may join later, have script or programming access rights. This user can then insert script rendering macros that are executed for those users in the realtime session that have script or programming rights. The inserted scripts can be used to gain more access rights.
Here's an example that works with XWiki 15.10.9+ and 16.2.0+:
the attacker starts editing a wiki page in realtime (for which they have edit right) another user, with script or programming access right joins the editing session (e.g. by clicking on a link / URL provided by the attacker) the attacker inserts a script rendering macro, say {{velocity}}I can run scripts{{/velocity}}, in the edited content, using the WYSIWYG editor UI the edited content is reloaded for both the attacker and the other user, in order to render the inserted macro the attacker gets a rendering error message the other user sees "I can run scripts"
The attacker can obviously use more advanced scripts to gain access rights.
Before XWiki 15.10.9 and 16.2.0 the edited content was not re-rendered for all the users in the editing sesesion, but only for the user that inserted the macro. This means that in order to reproduce the problem the other user had to insert or update a macro or save and view the content.
Patches
This vulnerability has been patched in XWiki 15.10.12, 16.4.1 and 16.6.0-rc-1.
Workarounds
To avoid this vulnerability you can:
either disable the realtime WYSIWYG editing by disabling the xwiki-realtime CKEditor plugin from the WYSIWYG editor administration section or uninstall the Realtime WYSIWYG Editor extension (org.xwiki.platform:xwiki-platform-realtime-wysiwyg-ui)
References
https://jira.xwiki.org/browse/XWIKI-21949
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
This vulnerability allows remote attackers to execute arbitrary code on affected installations of XWiki.org XWiki. Authentication is not required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 9.8.
This vulnerability allows remote attackers to execute arbitrary code on affected installations of XWiki.org XWiki. Authentication is not required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 9.8.
Impact Any user with script rights can perform arbitrary remote code execution by adding instances of XWiki.ConfigurableClass to any page. This compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on a instance, as a user with script rights, edit your user profile and add an object of type XWiki.ConfigurableClass ("Custom configurable sections"). Set "Display in section" and "Display in category" to other, "Scope" to Wiki and all spaces and "Heading" to: #set($codeToExecute = 'Test') #set($codeToExecuteResult = '{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"){{/groovy}}{{/async}}') Save the page and view it, then add ?sheet=XWiki.AdminSheet&viewer=content§ion=other to the URL. If the logs contain "attacker - Attack from Heading succeeded!", then the instance is vulnerable.
Patches This has been patched in XWiki 15.10.9 and 16.3.0.
Workarounds We're not aware of any workaround except upgrading.
References https://jira.xwiki.org/browse/XWIKI-21207 https://github.com/xwiki/xwiki-platform/commit/8493435ff9606905a2d913607d6c79862d0c168d
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 Any user with an account on the main wiki could run scheduling operations on subwikis. To reproduce, as a user on the main wiki without any special right, view the document Scheduler.WebHome in a subwiki. Then, click on any operation (e.g., Trigger) on any job. If the operation is successful, then the instance is vulnerable.
Patches This has been patched in XWiki 15.10.9 and 16.3.0.
Workarounds If you have subwikis where the Job Scheduler is enabled, you can edit the objects on Scheduler.WebPreferences to match https://github.com/xwiki/xwiki-platform/commit/54bcc5a7a2e440cc591b91eece9c13dc0c487331#diff-8e274bd0065e319a34090339de6dfe56193144d15fd71c52c1be7272254728b4.
References https://jira.xwiki.org/browse/XWIKI-21663 https://github.com/xwiki/xwiki-platform/commit/54bcc5a7a2e440cc591b91eece9c13dc0c487331
For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List
Impact
In getdocument.vm ; the ordering of the returned documents is defined from an unsanitized request parameter (request.sort) and can allow any user to inject HQL.
Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries.
It's possible to employ database backend dependent techniques of breaking out of HQL query context, described, for example, here: https://www.sonarsource.com/blog/exploiting-hibernate-injections.
Patches
This has been patched in 13.10.5 and 14.3-rc-1.
Workarounds
There is no known workaround, other than upgrading XWiki.
References
https://jira.xwiki.org/browse/XWIKI-17568
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 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
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
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 The REST API exposes the history of any page in XWiki of which the attacker knows the name. The exposed information includes for each modification of the page the time of the modification, the version number, the author of the modification (both username and displayed name) and the version comment. This information is exposed regardless of the rights setup, and even when the wiki is configured to be fully private.
On a private wiki, this can be tested by accessing /xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome/history, if this shows the history of the main page then the installation is vulnerable.
Patches This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1.
Workarounds There aren't any known workarounds apart from upgrading to a fixed version.
References https://jira.xwiki.org/browse/XWIKI-22052 https://github.com/xwiki/xwiki-platform/commit/9cbca9808300797c67779bb9a665d85cf9e3d4b8
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
A user without script/programming right can trick a user with elevated rights to edit a content with a malicious payload using a WYSIWYG editor. The user with elevated rights is not warned beforehand that they are going to edit possibly dangerous content. The payload is executed at edit time.
Patches
This vulnerability has been patched in XWiki 15.10RC1.
Workarounds
No workaround. It is advised to upgrade to XWiki 15.10+.
References
https://jira.xwiki.org/browse/XWIKI-20331 https://jira.xwiki.org/browse/XWIKI-21311 https://jira.xwiki.org/browse/XWIKI-21481 https://jira.xwiki.org/browse/XWIKI-21482 https://jira.xwiki.org/browse/XWIKI-21483 https://jira.xwiki.org/browse/XWIKI-21484 https://jira.xwiki.org/browse/XWIKI-21485 https://jira.xwiki.org/browse/XWIKI-21486 https://jira.xwiki.org/browse/XWIKI-21487 https://jira.xwiki.org/browse/XWIKI-21488 https://jira.xwiki.org/browse/XWIKI-21489 https://jira.xwiki.org/browse/XWIKI-21490
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
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
By creating a conflict when another user with more rights is currently editing a page, it is possible to execute JavaScript snippets on the side of the other user, which compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on a XWiki instance, a user with admin rights needs to edit a document without saving right away. Then, as another user without any other right than edit on the specific document, change the whole content to <script>alert('XSS')</script>. When the admin user then saves the document, a conflict popup appears. If they select "Fix each conflict individually" and see an alert displaying "XSS", then the instance is vulnerable.
Patches
This has been patched in XWiki 15.10.8 and 16.3.0RC1.
Workarounds
We're not aware of any workaround except upgrading.
References
https://jira.xwiki.org/browse/XWIKI-21626 https://github.com/xwiki/xwiki-platform/commit/821d43ec45e67d45a6735a0717b9b77fffc1cd9f
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
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
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
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 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 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 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 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 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 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 It is possible to schedule/trigger/unschedule existing jobs by having an admin visit the Job Scheduler page through a predictable URL, for example by embedding such an URL in any content as an image.
To reproduce in an XWiki installation, open <xwiki-host>:/xwiki/bin/view/Scheduler/?do=trigger&which=Scheduler.NotificationEmailDailySender as a user with admin rights. If there is no error message that indicates the CSRF token is invalid, the installation is vulnerable.
Patches The vulnerability has been fixed on XWiki 14.10.19, 15.5.5, and 15.9.
Workarounds Modify the Scheduler.WebHome page following this patch.
References - https://jira.xwiki.org/browse/XWIKI-20851 - https://github.com/xwiki/xwiki-platform/commit/f16ca4ef1513f84ce2e685d4a05d689bd3a2ab4c
Impact By creating a document with a specially crafted title, it is possible to trigger remote code execution in the (Solr-based) search in XWiki. This allows any user who can edit the title of a space (all users by default) to execute any Groovy code in the XWiki installation which compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce, as a user without script nor programming rights, create a document with title {{/html}}{{async}}{{groovy}}println("Hello from Groovy Title!"){{/groovy}}{{/async}} and content Test Document. Using the search UI, search for "Test Document", then deploy the Location facet on the right of the screen, next to the search results. The installation is vulnerable if you see an item such as: Hello from Groovy Title! </a> <div class="itemCount">1</div> </li> </ul> {{/html}}
Patches This has been patched in XWiki 14.10.20, 15.5.4 and 15.10 RC1.
Workarounds Modify the Main.SolrSpaceFacet page following this patch.
References https://jira.xwiki.org/browse/XWIKI-21471 https://github.com/xwiki/xwiki-platform/commit/acba74c149a041345b24dcca52c586f872ba97fb https://github.com/xwiki/xwiki-platform/commit/74e301c481e69eeea674dac7fed6af3614cf08c5