ghsa

### Impact XWiki is vulnerable to reflected cross-site scripting (RXSS) via the `rev` parameter that is used in the content of the content menu without escaping. If an attacker can convince a user to visit a link with a crafted parameter, this allows the attacker to execute arbitrary actions in the name of the user, including remote code (Groovy) execution in the case of a user with programming right, compromising the confidentiality, integrity and availability of the whole XWiki installation. The vulnerability can be demonstrated by opening `<xwiki-host>/xwiki/bin/view/Main/?rev=xar%3Aorg.xwiki.platform%3Axwiki-platform-distribution-flavor-common%2F15.5%25%25%22%3e%3cscript%3ealert(1)%3c%2fscript%3e` where `<xwiki-host>` is the URL of your XWiki installation. If an alert is displayed, the installation is vulnerable. ### Patches This has been patched in XWiki 15.6 RC1, 15.5.1 and 14.10.14. ### Workarounds The [patch](https://github.com/xwiki/xwiki-platform/commit/04e325d57d4bcb6ab7...

### Impact XWiki doesn't properly escape the section URL parameter that is used in the code for displaying administration sections. This allows any user with read access to the document `XWiki.AdminSheet` (by default, everyone including unauthenticated users) to execute code including Groovy code. This impacts the confidentiality, integrity and availability of the whole XWiki instance. By opening the URL `<server>/xwiki/bin/get/Main/WebHome?sheet=XWiki.AdminSheet&viewer=content&section=%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%7D%7D%7B%7Bgroovy%7D%7Dservices.logging.getLogger(%22attacker%22).error(%22Attack%20succeeded!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D&xpage=view` where `<server>` is the URL of the XWiki installation, it can be tested if an XWiki installation is vulnerable. If this causes a log message `ERROR attacker - Attack succeeded!` to appear in XWiki's log, the installation is vulnerable. In very old versions of XWiki, the attack can be demonstrated...

Deserialization of Untrusted Data, Improper Input Validation vulnerability in Apache UIMA Java SDK. This issue affects Apache UIMA Java SDK before 3.5.0. Users are recommended to upgrade to version 3.5.0, which fixes the issue. There are several locations in the code where serialized Java objects are deserialized without verifying the data. This affects in particular: * the deserialization of a Java-serialized CAS, but also other binary CAS formats that include TSI information using the CasIOUtils class; * the CAS Editor Eclipse plugin which uses the the CasIOUtils class to load data; * the deserialization of a Java-serialized CAS of the Vinci Analysis Engine service which can receive using Java-serialized CAS objects over network connections; * the CasAnnotationViewerApplet and the CasTreeViewerApplet; * the checkpointing feature of the CPE module. Note that the UIMA framework by default does not start any remotely accessible services (i.e. Vinci) that would be vulne...

A flaw was found in wildfly-core. A management user could use the resolve-expression in the HAL Interface to read possible sensitive information from the Wildfly system. This issue could allow a malicious user to access the system and obtain possible sensitive information from the system.

## Impact The vulnerability, known as RUSTSEC-2022-0093, impacts the `ed25519-dalek` crate, which is a dependency of the `rusty-paseto` crate. This issue arises from a "Double Public Key Signing Function Oracle Attack" affecting versions of `ed25519-dalek` prior to v2.0. These versions expose an unsafe API for serializing and deserializing 64-byte keypairs that include both private and public keys, creating potential for certain attacks. `d25519-dalek` users utilizing these serialization and deserialization functions directly could potentially be impacted. ## Patches The vulnerability within the `ed25519-dalek` crate has been addressed in version 2.0. `rusty-paseto` has addressed it in release v0.6.0. ## Workarounds Users are recommended to upgrade to v0.6.0 of `rusty-paseto`. However, users should still ensure that their key serialization and deserialization practices are secure and avoid any practices that could lead to key exposure. ## References More information about RUST...

### Impact In XWiki Platform, it's possible for a user to write a script in which any velocity content is executed with the right of any other document content author. To reproduce: As a user with script but not programming right, create a document with the following content: ``` {{velocity}} #set($main = $xwiki.getDocument('AppWithinMinutes.DynamicMessageTool')) $main.setTitle('$doc.getDocument().getContentAuthor()') $main.getPlainTitle() {{/velocity}} ``` Since this API require programming right and the user does not have it, the expected result is `$doc.document.authors.contentAuthor` (not executed script), unfortunately with the security vulnerability we get `XWiki.superadmin` which shows that the title was executed with the right of the unmodified document. ### Patches This has been patched in XWiki 14.10.7 and 15.2-RC-1. ### Workarounds There are no known workarounds for it. ### References * https://jira.xwiki.org/browse/XWIKI-20624 * https://github.com/xwiki/xwiki-pla...

### Impact In XWiki Platform, it's possible for a user to execute any content with the right of an existing document's content author, provided the user have edit right on it. The reason for this is that the edit action sets the content without modifying the content author. To reproduce: * Log in as a user without programming or script right. * Open the URL `<xwiki-host>/xwiki/bin/edit/<document>/?content=%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D&xpage=view`, where `<xwiki-host>` is the URL of your XWiki installation and `<document>` is the path to a document whose content author has programming right (or script right) and on which the current user has edit right. The text "Hello from Groovy!" is displayed in the page content, showing that the Groovy macro has been executed, which should not be the case for a user without programming right. ### Patches This has been patched in XWiki 14.10.6 and 15.2RC1. ### Workarounds There are no known work...

### Impact In XWiki Platform, it's possible to execute content with the right of any user if you can make this user follow a crafted URL. To reproduce: Get a user with programming rights to visit the URL `<xwiki-host>/xwiki/bin/edit/Main/?content=%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D&xpage=view`, where `<xwiki-host>` is the URL of your XWiki installation. This can be done by embedding an image with this URL. The text "Hello from Groovy!" is displayed in the page content, showing that the Groovy macro has been executed. ### Patches This has been patched in XWiki 14.10.7 and 15.2-RC-1. ### Workarounds There are no known workarounds for it. ### References * https://jira.xwiki.org/browse/XWIKI-20386 * https://github.com/xwiki/xwiki-platform/commit/cf8eb861998ea423c3645d2e5e974420b0e882be ### 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 ...

### Summary A bug in the RoleBinding reflector used by `capsule-proxy` gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name. ### Details - Tenant `solar`, owned by a ServiceAccount named `tenant-owner` in the Namespace `solar` - Tenant `wind`, owned by a ServiceAccount named `tenant-owner` in the Namespace `wind` > Please, notice the same ServiceAccount name, although in different namespaces. The Tenant owner `solar` would be able to list the namespaces of the Tenant `wind` and vice-versa, although this is not correct. The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions: 1. `capsule-proxy` runs with the `--disable-caching=false` (default value: `false`) 2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces. The CVE doesn't allow any privilege escalation on the outer ten...

Mattermost fails to properly sanitize the user object when updating the username, resulting in the password hash being included in the response body.