Source
ghsa
Affected versions receive a `&[u8]` from the caller through a safe API, and pass it directly to the unsafe `str::from_utf8_unchecked` function. The behavior of `ferris_says::say` is undefined if the bytes from the caller don't happen to be valid UTF-8. The flaw was corrected in [ferris-says#21] by using the safe `str::from_utf8` instead, and returning an error on invalid input. However this fix has not yet been published to crates.io as a patch version for 0.2. Separately, [ferris-says#32] has introduced a different API for version 0.3 which accepts input as `&str` rather than `&[u8]`, so is unaffected by this bug. [ferris-says#21]: https://github.com/rust-lang/ferris-says/pull/21 [ferris-says#32]: https://github.com/rust-lang/ferris-says/pull/32
### Impact In the Shopware CMS, the state handler for orders fails to sufficiently verify user authorizations for actions that modify the payment, delivery, and/or order status. Due to this inadequate implementation, users lacking 'write' permissions for orders are still able to change the order state. ### Patches Update to Shopware 6.5.7.4 ### Workarounds For older versions of 6.1, 6.2, 6.3 and 6.4 corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
### Impact The Shopware application API contains a search functionality which enables users to search through information stored within their Shopware instance. The searches performed by this function can be aggregated using the parameters in the “aggregations” object. The ‘name’ field in this “aggregations” object is vulnerable SQL-injection and can be exploited using time-based SQL-queries. ### Patches Update to Shopware 6.5.7.4 ### Workarounds For older versions of 6.1, 6.2, 6.3 and 6.4 corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
### Summary The revocation schema that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation. ### Details The revocation schema that is part of the Ursa CL-Signatures implementation has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation. The flaw exists in all CL-Signature versions published from the [Hyperledger Ursa] repository to the [Ursa Rust Crate], and are fixed in all versions published from the [Hyperledger AnonCreds CL-Signatures] repository to the [AnonCreds CL-Signatures Rust Crate]. To exploit the flaw, a holder must update...
### Summary The revocation scheme that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model. Notably, a malicious verifier may be able to generate a unique identifier for a holder providing a verifiable presentation that includes a Non-Revocation proof. ### Details The revocation scheme that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, potentially allowing a malicious verifier to generate a unique identifier for a holder that provides a verifiable presentation that includes a Non-Revocation proof. The flaws affects all CL-Signature versions published from the [Hyperledger Ursa] repository to the [Ursa Rust Crate], and is fixed in all versions published from the [Hyperledger AnonCreds CL-Signatures] repository to the [AnonCreds CL-Signatures Rust Crate]. The addressing the...
# CL Signatures Issuer Key Correctness Proof lacks of prime strength checking A weakness in the Hyperledger AnonCreds specification that is not mitigated in the Ursa and AnonCreds implementations is that the Issuer does not publish a key correctness proof demonstrating that a generated private key is sufficient to meet the unlinkability guarantees of AnonCreds. A sufficient private key is one in which it's components `p` and `q` are safe primes, such that: - `p` and `q` are both prime numbers - `p` and `q` are not equal - `p` and `q` have the same, sufficiently large, size - For example, using two values both 1024 bits long is sufficient, whereas using one value 2040 bits long and the other 8 bits long is not. The Ursa and AnonCreds CL-Signatures implementations always generate a sufficient private key. A malicious issuer could in theory create a custom CL Signature implementation (derived from the Ursa or AnonCreds CL-Signatures implementations) that uses weakened private keys su...
### Impact This vulnerability could have allowed an attacker to include arbitrary HTML content in search results by having a user search a malicious project. This was due to our search client not correctly escaping all user content from search results. You can find more information in the [advisory published in our readthedocs.org repo](https://github.com/readthedocs/readthedocs.org/security/advisories/GHSA-qhqx-5j25-rv48). Users of this extension should update to the 0.3.2 version, and trigger a new build. This issue was discovered by a member of our team, and we have seen no signs that this vulnerability was exploited in the wild. ### Patches This issue has been patched in our 0.3.2 version. ### References - https://github.com/readthedocs/readthedocs-sphinx-search/commit/8c6f6d01e88e72ef32ed0c220b6c19d1e1121c73 ### For more information If you have any questions or comments about this advisory, email us at [[email protected]](mailto:[email protected]) ([PGP](ht...
### Impact The default configuration of `@fastify/swagger-ui` without `baseDir` set will lead to all files in the module's directory being exposed via http routes served by the module. ### Patches Update to v2.1.0 ### Workarounds Use the `baseDir` option ### References [HackerOne report ](https://hackerone.com/reports/2312369).
### Summary A **stored cross-site scripting (XSS)** vulnerability was found in the **key_value** field of Avo v3.2.3. This vulnerability could allow an attacker to execute arbitrary JavaScript code in the victim's browser. ### Details The value of the key_value is inserted directly into the HTML code. In the current version of Avo (possibly also older versions), the value is not properly sanitized before it is inserted into the HTML code. This vulnerability can be exploited by an attacker to inject malicious JavaScript code into the key_value field. When a victim views the page containing the malicious code, the code will be executed in their browser. In [avo/fields/common/key_value_component.html.erb]( https://github.com/avo-hq/avo/blob/main/app/components/avo/fields/common/key_value_component.html.erb#L38C21-L38C33) the value is taken in lines **38** and **49** and seems to be interpreted directly as html in lines **44** and **55**. ### PoC  condition.