#jira

### Impact User without the right to view documents can deduce their existence by repeated Livetable queries. #### Reproduction steps 1. Restrict "view" access to `Sandbox.TestPage3` by setting an explicit view right for admins 1. As a user who is not an admin, open `<server>/bin/get/XWiki/LiveTableResults?outputSyntax=plain&classname=&collist=doc.title%2Cdoc.location%2Cdoc.content&doc.title=Sandbo&doc.location=Sandbox.TestPage3&doc.content=dummy&limit=0` where `<server>` is the URL of your XWiki installation. #### Expect Result: No results are displayed as the user doesn't have view rights on Sandbox.TestPage3. ##### Actual Result: The result ```json { "reqNo": null, "matchingtags": {}, "tags": [], "totalrows": 1, "returnedrows": 0, "offset": 1, "rows": [ { "doc_viewable": false, "doc_fullName": "obfuscated" } ] } ``` is displayed. This reveals that a document `Sandbox.TestPage3` exists (we explicitly searched for this name) which has a ti...

### Impact Any user with view rights on commonly accessible documents including the menu macro can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation due to improper escaping of the macro content and parameters of the menu macro. The issue can be demonstrated by opening `<server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%2F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7Bmenu%7D%7D%7B%7Bcache+id%3D%22menuMacro%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%7B%7B%2Fmenu%7D%7D` where `<server>` is the URL of the XWiki installation. If this displays "Hello from Groovy!", the installation is vulnerable. ### Patches The problem has been patched in XWiki 14.6RC1, 13.10.8 and 14.4.3. ### Workarounds The [patch](https://github.com/xwiki/xwiki-platform/commit/2fc20891e6c6b0ca05ee07e315e7f435e8919f8d) for the document `Menu....

### Impact We discovered that when the reset a forgotten password feature of XWiki was used, the password was then stored in plain text in database. This only concerns XWiki 13.1RC1 and next versions. Note that it only concerns the reset password feature available from the "Forgot your password" link in the login view: the features allowing a user to change their password, or for an admin to change a user password are not impacted. This vulnerability is particularly dangerous in combination with other vulnerabilities allowing to perform data leak of personal data from users, such as https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm. Note that this vulnerability only concerns the users of the main wiki: in case of farms, the users registered on subwiki are not impacted thanks to a bug we discovered when investigating this. ### Patches The problem has been patched in version 14.6RC1, 14.4.3 and 13.10.8. The patch involves a migration of the impacted u...

### Impact It's possible to make XWiki create many new schemas and fill them with tables just by using a crafted user identifier in the login form. ### Patches The problem has been patched in XWiki 13.10.8, 14.6RC1 and 14.4.2. ### Workarounds The only workarounds for this are: * use an authenticator which does interpret the login as a reference to a document * using a different database than PostgreSQL * upgrade XWiki ### References https://jira.xwiki.org/browse/XWIKI-19886 ### 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:[email protected])

### Impact Any user with view rights on commonly accessible documents including the icon picker macro can execute arbitrary Groovy, Python or Velocity code in XWiki due to improper neutralization of the macro parameters of the icon picker macro. The URL `<server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%252F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7BiconPicker%20id%3D%22'%3C%2Fscript%3E%7B%7B%2Fhtml%7D%7D%7B%7Bcache%7D%7D%7B%7Bgroovy%7D%7Dprintln(%2FHellofromIconPickerId%2F)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%22%20class%3D%22'%3C%2Fscript%3E%7B%7B%2Fhtml%7D%7D%7B%7Bcache%7D%7D%7B%7Bgroovy%7D%7Dprintln(%2FHellofromIconPickerClass%2F)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%22%2F%7D%7D` demonstrates the issue (replace `<server>` by the URL to your XWiki installation). If the output `HellofromIconPickerId` or `HellofromIconPickerClass` is visible, the XWiki installation is vulnerable (normally, all output should be conta...

### Impact Any user (logged in or not) with access to the page XWiki.XWikiUserProfileSheet can enable or disable any user profile. This might allow to a disabled user to re-enable themselves, or to an attacker to disable any user of the wiki. ### Patches The problem has been patched in XWiki 13.10.7, 14.5RC1 and 14.4.2. ### Workarounds The problem can be patched immediately by editing the page `XWiki.XWikiUserProfileSheet` in the wiki and by performing the changes contained in https://github.com/xwiki/xwiki-platform/commit/5be1cc0adf917bf10899c47723fa451e950271fa. ### References * https://github.com/xwiki/xwiki-platform/commit/5be1cc0adf917bf10899c47723fa451e950271fa * https://jira.xwiki.org/browse/XWIKI-19792 ### For more information If you have any questions or comments about this advisory: * Open an issue in [JIRA](https://jira.xwiki.org) * Email us at [security ML](mailto:[email protected])

### Impact It's possible for a user with only Script rights to enable or disable a user: this operation should be only doable for users with admin rights. ### Patches This problem has been patched in XWiki 13.10.7, 14.4.2 and 14.5RC1. ### Workarounds There is no workaround other than upgrading the wiki, but note that this only impacts users with Script rights: administrator should take care which users have such right. ### References * https://jira.xwiki.org/browse/XWIKI-19804 * https://github.com/xwiki/xwiki-platform/commit/0b732f2ef0224e2aaf10e2e1ef48dbd3fb6e10cd ### For more information If you have any questions or comments about this advisory: * Open an issue in [JIRA](https://jira.xwiki.org) * Email us at [security ML](mailto:[email protected])

### Impact Any user with the right to edit his personal page can follow one of the scenario below: **Scenario 1**: - Log in as a simple user with just edit rights on the user profile - Go to the user's profile - Upload an attachment in the attachment tab at the bottom of the page (any image is fine) - Click on "rename" in the attachment list and enter `{{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello from groovy!"){{/groovy}}{{/async}}.png` as new attachment name and submit the rename - Go back to the user profile - Click on the edit icon on the user avatar - `Hello from groovy!` is displayed as the title of the attachment **Scenario 2**: - Log in as a simple user with just edit rights on a page - Create a Page `MyPage.WebHome` - Create an XClass field of type String named `avatar` - Add an XObject of type `MyPage.WebHome` on the page - Insert an `attachmentSelector` macro in the document with the following values: - **classname**: `MyPage.WebHo...

### Impact It's possible with a simple request to perform deletion or renaming of tags without needing any confirmation, by using a CSRF attack. ### Patches The problem has been patched in XWiki 13.10.7, 14.4.1 and 14.5RC1. ### Workarounds It's possible to patch existing instances directly by editing the page Main.Tags and add this kind of check, in the code for renaming and for deleting: ``` #if (!$services.csrf.isTokenValid($request.get('form_token'))) #set ($discard = $response.sendError(401, "Wrong CSRF token")) #end ``` See the commit with the fix for more information about patching the page: https://github.com/xwiki/xwiki-platform/commit/7fd4cda0590180c4d34f557597e9e10e263def9e ### References * https://jira.xwiki.org/browse/XWIKI-19748 * https://github.com/xwiki/xwiki-platform/commit/7fd4cda0590180c4d34f557597e9e10e263def9e ### For more information If you have any questions or comments about this advisory: * Open an issue in [JIRA](https://jira.xwiki.org) * Ema...

Red Hat Security Advisory 2022-7874-01 - Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.8.53. Issues addressed include a code execution vulnerability.