#jira

### Impact The rollback action is missing a right protection: it means that a user can rollback to a previous version of the page to gain rights they don't have anymore. This vulnerability impacts all version of XWiki since rollback action is available. ### Patches The problem has been patched in XWiki 14.10.16, 15.5.3 and 15.8-rc-1 by ensuring that the rights are checked before performing the rollback. ### Workarounds There's no workaround for this vulnerability, except paying attention to delete old versions of documents that could allow users to gain more rights. ### References * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-21257 * Commit: [4de72875ca49602796165412741033bfdbf1e680](https://github.com/xwiki/xwiki-platform/commit/4de72875ca49602796165412741033bfdbf1e680) ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@x...

Apache OFBiz version 18.12.09 suffers from a pre-authentication remote code execution vulnerability.

### Impact It's possible to execute a Velocity script without script right through the document tree. To reproduce: * As a user without script right, create a document, e.g., named Nasty Title * Set the document's title to `$request.requestURI` * Click "Save & View" * Reload the page in the browser The navigation panel displays a document named with the current URL, showing that the Velocity code has been executed even though the user doesn't have script right. ### Patches This has been patched in XWiki 14.10.7 and 15.2RC1. ### Workarounds A possible workaround is to: * modify the page XWiki.DocumentTreeMacros * search for the code `#set ($discard = $translatedDocument.setTitle($translatedDocument.title))` * modify it into `#set ($discard = $translatedDocument.setcomment(''))` ### References * https://jira.xwiki.org/browse/XWIKI-20625 * https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3 ### For more information If you have any questions ...

This improper authorization vulnerability allows an unauthenticated attacker to reset Confluence and create a Confluence instance administrator account. Using this account, an attacker can then perform all administrative actions that are available to the Confluence instance administrator. This Metasploit module uses the administrator account to install a malicious .jsp servlet plugin which the user can trigger to gain code execution on the target in the context of the of the user running the confluence server.

### 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&section=othe...

### 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](https://github.com/xwiki/xwiki-platform/security/advisories/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 vulner...

### 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 labe...

### 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](https://twitter.com/ynoofAssiri) @Ynoof5.

### 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](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-q2hm-2h45-v5g3), 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 ...

XWiki Platform is a generic wiki platform. Starting in 7.2-milestone-2 and prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, 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. 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. This has been patched in XWiki 14.10.15, 15.5.2 and 15.7RC1. There are no known workarounds for this vulnerability.