ghsa

### Impact Any application using @fastify/websocket could crash if a specific, malformed packet is sent. All versions of fastify-websocket are also impacted. That module is deprecated, so it will not be patched. ### Patches This has been patched in v7.1.1 (fastify v4) and v5.0.1 (fastify v3). ### Workarounds No known workaround is available. However, it should be possible to attach the error handler manually. The recommended path is upgrading to the patched versions. ## Credits [marcolanaro](https://github.com/marcolanaro) for finding and patching this vulnerability ### For more information If you have any questions or comments about this advisory: * Open an issue in [@fastify/websocket](https://github.com/fastify/fastify-websocket) * Email us at [[email protected]](mailto:[email protected])

Apache Commons BCEL has a number of APIs that would normally only allow changing specific class characteristics. However, due to an out-of-bounds writing issue, these APIs can be used to produce arbitrary bytecode. This could be abused in applications that pass attacker-controllable data to those APIs, giving the attacker more control over the resulting bytecode than otherwise expected. Update to Apache Commons BCEL 6.6.0.

When Apache Ivy downloads artifacts from a repository it stores them in the local file system based on a user-supplied "pattern" that may include placeholders for artifacts coordinates like the organisation, module or version. If said coordinates contain "../" sequences - which are valid characters for Ivy coordinates in general - it is possible the artifacts are stored outside of Ivy's local cache or repository or can overwrite different artifacts inside of the local cache. In order to exploit this vulnerability an attacker needs collaboration by the remote repository as Ivy will issue http requests containing ".." sequences and a "normal" repository will not interpret them as part of the artifact coordinates. Users of Apache Ivy 2.0.0 to 2.5.1 should upgrade to Ivy 2.5.1.

btcd before 0.23.2, as used in Lightning Labs lnd before 0.15.2-beta and other Bitcoin-related products, mishandles witness size checking.

With Apache Ivy 2.4.0 an optional packaging attribute has been introduced that allows artifacts to be unpacked on the fly if they used pack200 or zip packaging. For artifacts using the "zip", "jar" or "war" packaging Ivy prior to 2.5.1 doesn't verify the target path when extracting the archive. An archive containing absolute paths or paths that try to traverse "upwards" using ".." sequences can then write files to any location on the local fie system that the user executing Ivy has write access to. Ivy users of version 2.4.0 to 2.5.0 should upgrade to Ivy 2.5.1.

Code Injection in GitHub repository froxlor/froxlor prior to version 0.10.38.2. There are currently no known workarounds, please upgrade to version 0.10.38.2.

The Apache Pulsar C++ Client does not verify peer TLS certificates when making HTTPS calls for the OAuth2.0 Client Credential Flow, even when tlsAllowInsecureConnection is disabled via configuration. This vulnerability allows an attacker to perform a man in the middle attack and intercept and/or modify the GET request that is sent to the ClientCredentialFlow 'issuer url'. The intercepted credentials can be used to acquire authentication data from the OAuth2.0 server to then authenticate with an Apache Pulsar cluster. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack. The Apache Pulsar Python Client wraps the C++ client, so it is also vulnerable in the same way. This issue affects Apache Pulsar C++ Client and Python Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0 to 2.10.1; 2.6.4 and earlier. Any users running affecte...

TiDB is vulnerable to Use of Externally-Controlled Format String. A patch is available on the `master` branch and expected to be part of versions 6.4.0 and 6.1.3.

Froxlor prior to version 0.10.39 is vulnerable to Code Injection.

### Impact Even if a wiki has an OpenID provider configured through its xwiki.properties, it is possible to provide a third party provider by providing its details through request parameters. One can then bypass the XWiki authentication altogether by specifying its own provider through the oidc.endpoint.* request parameters (or by using an XWiki-based OpenID provider with oidc.xwikiprovider. With the same approach, one could also provide a specific group mapping through oidc.groups.mapping that would make his user automatically part of the XWikiAdminGroup ### Patches Patched in 1.29.1. ### Workarounds There is no workaround, an upgrade of the authenticator is required. ### References https://jira.xwiki.org/browse/OIDC-118 ### For more information If you have any questions or comments about this advisory: * Open an issue in Jira XWiki * Email us at our security mailing list