ghsa

The default configuration of XSLTResourceStream.java is vulnerable to remote code execution via XSLT injection when processing input from an untrusted source without validation. Users are recommended to upgrade to versions 10.1.0, 9.18.0 or 8.16.0, which fix this issue.

### Summary A time/boolean SQL Injection is present in the following resource `/api/applicationResources` via the following parameter `packageID` ### Details As it can be seen [here](https://github.com/openclarity/kubeclarity/blob/main/backend/pkg/database/id_view.go#L79), while building the SQL Query the `fmt.Sprintf` function is used to build the query string without the input having first been subjected to any validation. ### PoC The following command should be able to trigger a basic version of the behavior: `curl -i -s -k -X $'GET' \ -H $'Host: kubeclarity.test' \ $'https://kubeclarity.test/api/applicationResources?page=1&pageSize=50&sortKey=vulnerabilities&sortDir=DESC&packageID=c89973a6-4e7f-50b5-afe2-6bf6f4d3da0a\'HTTP/2'` ### Impact While using the Helm chart, the impact of this vulnerability is limited since it allows read access only to the kuberclarity database, to which access is already given as far as I understand to regular users anyway. On the other hand, if...

Vault and Vault Enterprise did not properly handle requests originating from unauthorized IP addresses when the TCP listener option, proxy_protocol_behavior, was set to deny_unauthorized. When receiving a request from a source IP address that was not listed in proxy_protocol_authorized_addrs, the Vault API server would shut down and no longer respond to any HTTP requests, potentially resulting in denial of service. While this bug also affected versions of Vault up to 1.17.1 and 1.16.5, a separate regression in those release series did not allow Vault operators to configure the deny_unauthorized option, thus not allowing the conditions for the denial of service to occur. Fixed in Vault and Vault Enterprise 1.17.2, 1.16.6, and 1.15.12.

NATS.io NATS Server before 2.8.2 and Streaming Server before 0.24.6 could allow a remote attacker to bypass security restrictions, caused by the failure to enforce negative user permissions in one scenario. By using a queue subscription on the wildcard, an attacker could exploit this vulnerability to allow denied subjects.

### Impact The Auth0 WordPress plugin allows site administrators to opt-in to allowing the use of a `wle` parameter, which can be passed to the WordPress login page by end users. When this parameter is supplied using an expected value (which is randomly generated by the plugin, by default), the end user can fallback to using WordPress' native authentication behavior. (This is generally intended as an emergency fallback for administrators to still be able to access their dashboard in the event something goes wrong.) In previous versions of the plugin, under specific conditions, this parameter could potentially accept an arbitrary string that would be improperly rendered, potentially allowing for a cross-site scripting (XSS) attack on the login page. ### Patches Please upgrade to v4.6.1 of the plugin to resolve the issue.

### Summary Denial of service vulnerability. ### Details See: https://github.com/advisories/GHSA-447r-wph3-92pm and https://github.com/dotnet/announcements/issues/312 ### PoC Update System.Security.Cryptography.Pkcs to 8.0.1 so that the transitive dependency with the issue gets updated ### Impact Denial of service vulnerability. Affects MimeKit (>= v3.0.0 and <= v4.7.0) when used to decrypt or verify incoming S/MIME messages as well as importing 3rd-party X.509 certificates for use with encrypting outgoing S/MIME messages.

### Impact Due to a bug in Red's Core API, 3rd-party cogs using the [`@commands.can_manage_channel()`](https://docs.discord.red/en/stable/framework_checks.html#redbot.core.commands.can_manage_channel) command permission check without additional permission controls may authorize a user to run a command even when that user doesn't have permissions to manage a channel. None of the core commands or core cogs are affected. The maintainers of the project are not aware of any _public_ 3rd-party cog utilizing this API at the time of writing this advisory. The [`@commands.mod_or_can_manage_channel()`](https://docs.discord.red/en/stable/framework_checks.html#redbot.core.commands.mod_or_can_manage_channel), [`@commands.admin_or_can_manage_channel()`](https://docs.discord.red/en/stable/framework_checks.html#redbot.core.commands.admin_or_can_manage_channel), and [`@commands.guildowner_or_can_manage_channel()`](https://docs.discord.red/en/stable/framework_checks.html#redbot.core.commands.guildowne...

### Impact A bug in Wagtail's [`parse_query_string`](https://docs.wagtail.org/en/stable/topics/search/searching.html#wagtailsearch-query-string-parsing) would result in it taking a long time to process suitably crafted inputs. When used to parse sufficiently long strings of characters without a space, `parse_query_string` would take an unexpectedly large amount of time to process, resulting in a denial of service. In an initial Wagtail installation, the vulnerability can be exploited by any Wagtail admin user. It cannot be exploited by end users. If your Wagtail site has a custom search implementation which uses `parse_query_string`, it may be exploitable by other users (e.g. unauthenticated users). ### Patches Patched versions have been released as Wagtail 5.2.6, 6.0.6 and 6.1.3. This vulnerability affects all unpatched versions from Wagtail 2.0 onwards. ### Workarounds Site owners who are unable to upgrade to a patched version can limit the length of search terms passed to `pa...

Authentication would not be properly validated when an already authenticated scope user would use the `use` method or `USE` clause to switch working databases in a session. If there was a user record in the new database with identical record identifier as the original record that the user authenticated with in the original database, this could result in the user being able to perform actions under the identity of the unrelated user in the new database. This issue does not affect system users at any level. By default, record identifiers are randomly generated with sufficient complexity to prevent the identifier collision required to trigger this issue. However, the issue may trigger in situations where multiple databases in the same SurrealDB instance are using explicitly defined or incremental record identifiers to identify users on an identically named table. ### Impact Under the circumstances described above, a user who has an authenticated session as a scope user in a database co...

### Summary An issue in the OpenSearch observability plugins allows unintended access to private tenant resources like notebooks. The system did not properly check if the user was the resource author when accessing resources in a private tenant, leading to potential data being revealed. ### Impact The lack of proper access control validation for private tenant resources in the OpenSearch observability and reporting plugins can lead to unintended data access. If an authorized user with observability or reporting roles is aware of another user's private tenant resource ID, such as a notebook, they can potentially read, modify, or take ownership of that resource, despite not being the original author, thus impacting the confidentiality and integrity of private tenant resources. The impact is confined to private tenant resources, where authorized users may gain inappropriate visibility into data intended to be private from other users within the same OpenSearch instance, potentially vio...