ghsa

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