ghsa

### 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 request to `/api/v4/redirect_location` allowing an attacker, sending a specially crafted request to `/api/v4/redirect_location`, to fill up the memory due to caching large items.

Mattermost fails to properly validate requests to the Calls plugin, allowing an attacker sending a request without a User Agent header to cause a panic and crash the Calls plugin

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

In certain conditions for Calico Typha (v3.26.2, v3.25.1 and below), and Calico Enterprise Typha (v3.17.1, v3.16.3, v3.15.3 and below), a client TLS handshake can block the Calico Typha server indefinitely, resulting in denial of service. The TLS Handshake() call is performed inside the main server handle for loop without any timeout allowing an unclean TLS handshake to block the main loop indefinitely while other connections will be idle waiting for that handshake to finish.

** UNSUPPPORTED WHEN ASSIGNED ** ** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in Magnesium-PHP up to 0.3.0. It has been classified as problematic. Affected is the function formatEmailString of the file `src/Magnesium/Message/Base.php`. The manipulation of the argument email/name leads to injection. Upgrading to version 0.3.1 is able to address this issue. The patch is identified as 500d340e1f6421007413cc08a8383475221c2604. It is recommended to upgrade the affected component. VDB-244482 is the identifier assigned to this vulnerability. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

### Impact The route used for file downloads allows specifying the name of the downloaded file. This is an unintended side effect of the implementation, and means one could construct download URLs with filenames that have no relation to the actual file, which could lead to misunderstandings and confusion, and possibly other harm. As such it is a low severity vulnerability. It affects all supported versions of Ibexa DXP and eZ Platform, in installations where downloadable files exist. ### Patches The issue is fixed in all supported versions of ezsystems/ezplatform-kernel, see "Patched versions". An advisory is also published for ezsystems/ezpublish-kernel and ibexa/core, please see those repositories. Commit: https://github.com/ezsystems/ezplatform-kernel/commit/affa2520e5e986e477ca7f7c93b9ca2c30188063 ### Workarounds None, other than blocking all downloads. ### References https://developers.ibexa.co/security-advisories/ibexa-sa-2023-005-vulnerabilities-in-solr-search-and-file-downlo...

### Impact The route used for file downloads allows specifying the name of the downloaded file. This is an unintended side effect of the implementation, and means one could construct download URLs with filenames that have no relation to the actual file, which could lead to misunderstandings and confusion, and possibly other harm. As such it is a low severity vulnerability. It affects all supported versions of Ibexa DXP and eZ Platform, in installations where downloadable files exist. ### Patches The issue is fixed in all supported versions of ibexa/core, see "Patched versions". An advisory is also published for ezsystems/ezpublish-kernel and ezsystems/ezplatform-kernel, please see those repositories. Commit: https://github.com/ibexa/core/commit/704f221031ea4e32bd5510fe4c1fa8e0f664cbd4 ### Workarounds None, other than blocking all downloads. ### References https://developers.ibexa.co/security-advisories/ibexa-sa-2023-005-vulnerabilities-in-solr-search-and-file-downloads