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
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
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
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 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 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 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 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 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
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
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions any user with SCRIPT right can save a document with the right of the current user which allow accessing API requiring programming right if the current user has programming right. This has been patched in XWiki 13.0. Users are advised to update to resolve this issue. The only known workaround is to limit SCRIPT access.
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions it's possible for an unprivileged user to perform a remote code execution by injecting a groovy script in her own profile and by calling the Reset password feature since the feature is performing a save of the user profile with programming rights in the impacted versions of XWiki. The issue has been patched in XWiki 13.1RC1. There are two different possible workarounds, each consisting of modifying the XWiki/ResetPassword page. 1. The Reset password feature can be entirely disabled by deleting the XWiki/ResetPassword page. 2. The script in XWiki/ResetPassword can also be modified or removed: an administrator can replace it with a simple email contact to ask an administrator to reset the password.
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions any user with edit right can copy the content of a page it does not have access to by using it as template of a new page. This issue has been patched in XWiki 13.2CR1 and 12.10.6. Users are advised to update. There are no known workarounds for this issue.
Impact There's no protection against URL redirection to untrusted site, in particular some well known parameters (xredirect) can be used to perform such redirections.
Patches The problem has been patched in XWiki 12.10.7 and XWiki 13.3RC1.
Workarounds There's no known workaround for this issue.
References https://jira.xwiki.org/browse/XWIKI-10309
For more information If you have any questions or comments about this advisory: Open an issue in JIRA Email us at Security ML
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions it's possible to guess if a user has an account on the wiki by using the "Forgot your password" form, even if the wiki is closed to guest users. This problem has been patched on XWiki 12.10.9, 13.4.1 and 13.6RC1. Users are advised yo update. There are no known workarounds for this issue.
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions AbstractSxExportURLFactoryActionHandler#processSx does not escape anything from SSX document references when serializing it on filesystem, it is possible to for the HTML export process to contain reference elements containing filesystem syntax like "../", "./". or "/" in general. The referenced elements are not properly escaped. This issue has been resolved in version 13.6-rc-1. This issue can be worked around by limiting or disabling document export.
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions any user with SCRIPT right can read any file located in the XWiki WAR (for example xwiki.cfg and xwiki.properties) through XWiki#invokeServletAndReturnAsString as $xwiki.invokeServletAndReturnAsString("/WEB-INF/xwiki.cfg"). This issue has been patched in XWiki versions 12.10.9, 13.4.3 and 13.7-rc-1. Users are advised to update. The only workaround is to limit SCRIPT right.
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions there is a cross site scripting (XSS) vector in the registerinline.vm template related to the xredirect hidden field. This template is only used in the following conditions: 1. The wiki must be open to registration for anyone. 2. The wiki must be closed to view for Guest users or more specifically the XWiki.Registration page must be forbidden in View for guest user. A way to obtain the second condition is when administrators checked the "Prevent unregistered users from viewing pages, regardless of the page rights" box in the administration rights. This issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, 13.10.3. There are two main ways for protecting against this vulnerability, the easiest and the best one is by applying a patch in the registerinline.vm template, the patch consists in checking the value of the xredirect field to ensure it matches: <input type="hidden" name="xredirect" value="$escapetool.xml($!request.xredirect)" />. If for some reason it's not possible to patch this file, another workaround is to ensure "Prevent unregistered users from viewing pages, regardless of the page rights" is not checked in the rights and apply a better right scheme using groups and rights on spaces.
Impact XWiki Crypto API will generate X509 certificates signed by default using SHA1 with RSA, which is not considered safe anymore for use in certificate signatures, due to the risk of collisions with SHA1. Note that this API is never used in XWiki Standard but it might be used in some extensions of XWiki.
Patches The problem has been patched in XWiki version 13.10.6, 14.3.1 and 14.4-rc-1. Since then, the Crypto API will generate X509 certificates signed by default using SHA256 with RSA.
Workarounds Administrators are advised to upgrade their XWiki installation to one of the patched versions. If the upgrade is not possible, it is possible to patch the module xwiki-platform-crypto in a local installation by applying the change exposed in https://github.com/xwiki/xwiki-platform/commit/26728f3f23658288683667a5182a916c7ecefc52 and re-compiling the module.
References https://jira.xwiki.org/browse/XWIKI-19676 https://github.com/openssl/openssl/blob/master/CHANGES.md?plain=1#L938 https://github.com/openssl/openssl/issues/16650
For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki Email us at security ML
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Starting with version 8.3-rc-1 and prior to versions 12.10.3 and 14.0, one can ask for any file located in the classloader using the template API and a path with ".." in it. The issue is patched in versions 14.0 and 13.10.3. There is no easy workaround for this issue.
XWiki Platform Wiki UI Main Wiki is a package for managing subwikis. Starting with version 5.3-milestone-2, XWiki Platform Wiki UI Main Wiki contains a possible cross-site scripting vector in the WikiManager.JoinWiki wiki page related to the "requestJoin" field. The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, and 13.10.3. The easiest available workaround is to edit the wiki page WikiManager.JoinWiki (with wiki editor) according to the suggestion provided in the GitHub Security Advisory.
XWiki Platform Flamingo Theme UI is a tool that allows customization and preview of any Flamingo-based skin. Starting with versions 6.2.4 and 6.3-rc-1, a possible cross-site scripting vector is present in the FlamingoThemesCode.WebHomeSheet wiki page related to the "newThemeName" form field. The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, and 13.10.3. The easiest available workaround is to edit the wiki page FlamingoThemesCode.WebHomeSheet (with wiki editor) according to the suggestion provided in the GitHub Security Advisory.
XWiki Platform Filter UI provides a generic user interface to convert from a XWiki Filter input stream to an output stream with settings for each stream. Starting with versions 6.0-milestone-2 and 5.4.4 and prior to versions 12.10.11, 14.0-rc-1, 13.4.7, and 13.10.3, XWiki Platform Filter UI contains a possible cross-site scripting vector in the Filter.FilterStreamDescriptorForm wiki page related to pretty much all the form fields printed in the home page of the application. The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, and 13.10.3. The easiest workaround is to edit the wiki page Filter.FilterStreamDescriptorForm (with wiki editor) according to the instructions in the GitHub Security Advisory.
XWiki Platform Web Templates are templates for XWiki Platform, a generic wiki platform. Through the suggestion feature, string and list properties of objects the user shouldn't have access to can be accessed in versions prior to 13.10.4 and 14.2. This includes private personal information like email addresses and salted password hashes of registered users but also other information stored in properties of objects. Sensitive configuration fields like passwords for LDAP or SMTP servers could be accessed. By exploiting an additional vulnerability, this issue can even be exploited on private wikis at least for string properties. The issue is patched in version 13.10.4 and 14.2. Password properties are no longer displayed and rights are checked for other properties. A workaround is available. The template file suggest.vm can be replaced by a patched version without upgrading or restarting XWiki unless it has been overridden, in which case the overridden template should be patched, too. This might need adjustments for older versions, though.
XWiki Platform Old Core is a core package for XWiki Platform, a generic wiki platform. Prior to versions 14.2 and 13.10.4, all rights checks that would normally prevent a user from viewing a document on a wiki can be bypassed using the login action and directly specified templates. This exposes title, content and comments of any document and properties of objects, though class and property name must be known. This is also exploitable on private wikis. This has been patched in versions 14.2 and 13.10.4 by properly checking view rights before loading documents and disallowing non-default templates in the login, registration and skin action. As a workaround, it would be possible to protect all templates individually by adding code to check access rights first.
XWiki Platform Web Templates are templates for XWiki Platform, a generic wiki platform. By passing a template of the distribution wizard to the xpart template, user accounts can be created even when user registration is disabled. This also circumvents any email verification. Before versions 14.2 and 13.10.4, this can also be exploited on a private wiki, thus potentially giving the attacker access to the wiki. Depending on the configured default rights of users, this could also give attackers write access to an otherwise read-only public wiki. Users can also be created when an external authentication system like LDAP is configured, but authentication fails unless the authentication system supports a bypass/local accounts are enabled in addition to the external authentication system. This issue has been patched in XWiki 13.10.5 and 14.3RC1. As a workaround, one may replace xpart.vm, the entry point for this attack, by a patched version from the patch without updating XWiki.
XWiki Platform is a generic wiki platform. Prior to versions 13.10.5 and 14.3, it is possible to perform a Cross-Site Request Forgery (CSRF) attack for adding or removing tags on XWiki pages. The problem has been patched in XWiki 13.10.5 and 14.3. As a workaround, one may locally modify the documentTags.vm template in one's filesystem, to apply the changes exposed there.
The XWiki Platform Index UI is an Index of all pages, attachments, orphans and deleted pages and attachments for XWiki Platform, a generic wiki platform. Prior to versions 13.10.6 and 14.3, it's possible to store JavaScript which will be executed by anyone viewing the deleted attachments index with an attachment containing javascript in its name. This issue has been patched in XWiki 13.10.6 and 14.3. As a workaround, modify fix the vulnerability by editing the wiki page XWiki.DeletedAttachments with the object editor, open the JavaScriptExtension object and apply on the content the changes that can be found on the fix commit.
Impact It's possible to know if a user has or not an account in a wiki related to an email address, and which username(s) is actually tied to that email by forging a request to the Forgot username page. Note that since this page does not have a CSRF check it's quite easy to perform a lot of those requests. ### Patches This issue has been patched in XWiki 12.10.5 and 13.2RC1. Two different patches are provided: - a first one to fix the CSRF problem - a more complex one that now relies on sending an email for the Forgot username process. ### Workarounds It's possible to fix the problem without uprading by editing the ForgotUsername page in version below 13.x, to use the following code: https://github.com/xwiki/xwiki-platform/blob/69548c0320cbd772540cf4668743e69f879812cf/xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-ui/src/main/resources/XWiki/ForgotUsername.xml#L39-L123 In version after 13.x it's also possible to edit manually the forgotusername.vm file, but it's really encouraged to upgrade the version here. ### References https://jira.xwiki.org/browse/XWIKI-18384 https://jira.xwiki.org/browse/XWIKI-18408 ### For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki Email us at security ML
Impact When using default XWiki configuration, it's possible for an attacker to upload an SVG containing a script executed when executing the download action on the file.
Patches This problem has been patched so that the default configuration doesn't allow to display the SVG files in the browser.
Workarounds This issue can be fixed without the patch by setting properly the configuration to download or display files, see: https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments#HAttachmentdisplayordownload
References https://jira.xwiki.org/browse/XWIKI-18368
For more information If you have any questions or comments about this advisory: Open an issue in Jira Email us at security ML