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 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 The Solr-based search in XWiki discloses the password hashes of all users to anyone with view right on the respective user profiles. By default, all user profiles are public. To reproduce, it is sufficient to search for propertyvalue:? AND reference:.password and then deselect the "Document" property under "Result type" in the "Refine your search" widget at the right of the search results. If this displays any passwords or password hashes, the installation is vulnerable.
By default, passwords in XWiki are salted and hashed with SHA-512. On XWiki versions affected by CVE-2022-41933, passwords are stored in plain text if they have been set using the password reset feature. This might affect XWiki installations that are using an external authentication mechanism such that passwords aren't stored in the wiki.
This vulnerability also affects any configurations used by extensions that contain passwords like API keys that are viewable for the attacker. Normally, such passwords aren't accessible but this vulnerability would disclose them as plain text.
Patches This has been patched in XWiki 14.10.15, 15.5.2 and 15.7RC1. This vulnerability has been patched as part of patching GHSA-2grh-gr37-2283, the part of the fix that changes the indexing of single properties to use the same code as the main document for getting the property's value fixes this vulnerability.
Workarounds We're not aware of any workarounds apart from upgrading to a fixed version.
References https://github.com/xwiki/xwiki-platform/commit/3e5272f2ef0dff06a8f4db10afd1949b2f9e6eea https://jira.xwiki.org/browse/XWIKI-21208
Impact The Solr-based search in XWiki discloses the email addresses of users even when obfuscation of email addresses is enabled. To demonstrate the vulnerability, search for objcontent:email using XWiki's regular search interface.
Patches This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1 by not indexing email address properties when obfuscation is enabled. Further, changing the setting now triggers re-indexing of the affected wiki(s).
Workarounds We're not aware of any workarounds.
References https://jira.xwiki.org/browse/XWIKI-20371 https://github.com/xwiki/xwiki-platform/commit/3e5272f2ef0dff06a8f4db10afd1949b2f9e6eea
Attribution This vulnerability was reported on Intigriti by ynoof @Ynoof5.