ghsa

### Impact An attacker is able allocate arbitrarily many bytes in the Bitswap server by sending many `WANT_BLOCK` and or `WANT_HAVE` requests which are queued in an unbounded queue, with allocations that persist even if the connection is closed. This affects users accepting or connecting untrusted connections such as by running in the public swarm and no pnet config. Nodes that are not publicly reachable but connects to untrusted nodes are also vulnerable to the untrusted nodes being connected to since libp2p connections are blindly bidirectional. ### Patches - 19feb15833c6f4d6e7f1e1b132efaae96d76481d [`boxo`](https://github.com/ipfs/boxo) update in Kubo - GHSA-m974-xj4j-7qv5 patches in boxo ### Workarounds Use [PNET](https://github.com/ipfs/kubo/blob/master/docs/experimental-features.md#private-networks), [swarm filters](https://github.com/ipfs/kubo/blob/master/docs/config.md#swarmaddrfilters) or [resource manager allows list](https://pkg.go.dev/github.com/libp2p/go-libp2p/p2p/hos...

This package has been moved to [`github.com/ipfs/boxo/bitswap`](https://pkg.go.dev/github.com/ipfs/boxo/bitswap), this vulnerability is tracked there: https://github.com/ipfs/boxo/security/advisories/GHSA-m974-xj4j-7qv5 (`CVE-2023-25568`) ### Remediation This is a two step process: 1. Apply one of: - (**recommended**) upgrade from `github.com/ipfs/go-bitswap` to `github.com/ipfs/boxo/bitswap`. - If you are still using `github.com/ipfs/go-bitswap` and cannot upgrade to `boxo`, you can upgrade to `github.com/ipfs/[email protected]`, this will replace the `go-bitswap` implementation by stubs which points to `boxo`. 2. Open https://github.com/ipfs/boxo/security/advisories/GHSA-m974-xj4j-7qv5 and then follow `boxo`'s remediation section. ### Vulnerable symbols - `>= v0.9.0; < v0.12.0` - `github.com/ipfs/go-bitswap/server/internal/decision.(*Engine).MessageReceived` - `github.com/ipfs/go-bitswap/server/internal/decision.(*Engine).NotifyNewBlocks` - `github.com/ipfs/go-bitswap/...

### Impact Systems that run `distribution` built after a specific commit running on memory-restricted environments can suffer from denial of service by a crafted malicious `/v2/_catalog` API endpoint request. ### Patches Upgrade to at least 2.8.2-beta.1 if you are running `v2.8.x` release. If you use the code from the main branch, update at least to the commit after [f55a6552b006a381d9167e328808565dd2bf77dc](https://github.com/distribution/distribution/commit/f55a6552b006a381d9167e328808565dd2bf77dc). ### Workarounds There is no way to work around this issue without patching. Restrict access to the affected API endpoint: see the recommendations section. ### References `/v2/_catalog` endpoint accepts a parameter to control the maximum amount of records returned (query string: `n`). When not given the default `n=100` is used. The server trusts that `n` has an acceptable value, however when using a maliciously large value, it allocates an array/slice of `n` of strings before fi...

### Impact HTML rendering didn't check for dangerous attributes/attribute values. This allowed cross-site scripting (XSS) attacks via attributes and link URLs, e.g., supported in XWiki syntax. ### Patches This has been patched in XWiki 14.6 RC1. ### Workarounds There are no known workarounds apart from upgrading to a fixed version. ### References * https://github.com/xwiki/xwiki-rendering/commit/c40e2f5f9482ec6c3e71dbf1fff5ba8a5e44cdc1 * https://jira.xwiki.org/browse/XRENDERING-663 ### 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 us at [Security Mailing List](mailto:[email protected])

### Impact It's possible for a user to execute anything with the right of the author of the XWiki.ClassSheet document. **Steps to Reproduce:** 1. Edit your user profile with the object editor and add an object of type `DocumentSheetBinding` with value `Default Class Sheet` 1. Edit your user profile with the wiki editor and add the syntax `{{async}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}}` 1. Click "Save & View" **Expected result:** An error is displayed as the user doesn't have the right to execute the Groovy macro. **Actual result:** The text "Hello from groovy!" is displayed at the top of the document. ### Patches This has been patched in XWiki 15.0-rc-1 and 14.10.4. ### Workarounds There are no known workarounds for it. ### References https://jira.xwiki.org/browse/XWIKI-20566 https://github.com/xwiki/xwiki-platform/commit/de72760d4a3e1e9be64a10660a0c19e9534e2ec4 ### For more information If you have any questions or comments about this advisory:...

### Impact An attacker is able allocate arbitrarily many bytes in the Bitswap server by sending many `WANT_BLOCK` and or `WANT_HAVE` requests which are queued in an unbounded queue, with allocations that persist even if the connection is closed. This affects users accepting untrusted connections with the Bitswap server, this also affects users using the old API stubs at `github.com/ipfs/boxo/bitswap` because it transitively uses `github.com/ipfs/boxo/bitswap/server`. We have [renamed go-libipfs to boxo](https://github.com/ipfs/boxo/issues/215); this document uses both terms interchangeably. The version numbers for both are applicable, as they share the same historical timeline. ### Remediation Apply one of: - Update `boxo` to [`v0.6.0`](https://github.com/ipfs/boxo/releases/tag/v0.6.0) or later - Update `boxo` to [`v0.4.1`](https://github.com/ipfs/boxo/releases/tag/v0.4.1) Note that ***`v0.5.0` is NOT safe***, `v0.4.1` is a backport of the `v0.6.0` security fixes on top of `v0.4.0...

### Impact This vulnerability has the potential to steal a user's cookie and gain unauthorized access to that user's account through the stolen cookie or redirect users to other malicious sites. ### Patches Update to version 10.5.21 or apply this patch manually: https://github.com/pimcore/pimcore/commit/07a2c95be524c7e20105cef58c5767d4ebb06091.patch ### Workarounds Apply patches manually: https://github.com/pimcore/pimcore/commit/07a2c95be524c7e20105cef58c5767d4ebb06091.patch ### References https://huntr.dev/bounties/564cb512-2bcc-4458-8c20-88110ab45801/

### Impact This vulnerability impacts anyone running the affected versions of Wings. This vulnerability can be used to gain access to the host system running Wings if a user is able to modify an server's install script or the install script executes code supplied by the user (either through environment variables, or commands that execute commands based off of user data). ### Patches This vulnerability has been resolved in version `v1.11.6` of Wings, and has been back-ported to the 1.7 release series in `v1.7.5`. Anyone running `v1.11.x` should upgrade to `v1.11.6` and anyone running `v1.7.x` should upgrade to `v1.7.5`. ### Workarounds Running Wings with a rootless container runtime may mitigate the severity of any attacks, however the majority of users are using container runtimes that run as root as per our documentation. SELinux may prevent attackers from performing certain operations against the host system, however privileged containers have a lot of freedom even on systems...

### Impact Users can either intentionally or inadvertently create a shard containing `/` characters from VTAdmin such that from that point on, anyone who tries to create a new shard from VTAdmin will receive an error. Attempting to view the keyspace(s) will also no longer work. Creating a shard using `vtctldclient` does not have the same problem because the CLI validates the input correctly. ### Patches v16.0.2, corresponding to [0.16.2 on pkg.go.dev](https://pkg.go.dev/vitess.io/[email protected]) ### Workarounds - Always use `vtctldclient` to create shards, instead of using VTAdmin - Disable creating shards from VTAdmin using RBAC - Delete the topology record for the offending shard using the client for your topology server. For example, if you created a shard called `a/b` in keyspace `commerce`, and you are running etcd, it can be deleted by doing something like ``` % etcdctl --endpoints "http://${ETCD_SERVER}" del /vitess/global/keyspaces/commerce/shards/a/b/Shard ``` ### Referenc...

### Impact Business Logic Errors in the Conditions tab since the counter can be a negative number. This vulnerability is capable of the unlogic in the counter value in the Conditions tab. ### Patches Update to version 3.3.9 or apply this patch manually https://github.com/pimcore/customer-data-framework/commit/e3f333391582d9309115e6b94e875367d0ea7163.patch ### Workarounds Apply https://github.com/pimcore/customer-data-framework/commit/e3f333391582d9309115e6b94e875367d0ea7163.patch manually. ### References https://huntr.dev/bounties/cecd7800-a996-4f3a-8689-e1c2a1e0248a/