ghsa

## Summary A number of vulnerabilities have been found in `cosign verify-blob`, where Cosign would successfully verify an artifact when verification should have failed. ## Vulnerability 1: Bundle mismatch causes invalid verification. ### Summary A cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature. ### Details Cosign supports "bundles" which intend to allow offline verification of the signature and rekor inclusion. By using the --bundle flag in cosign sign-blob, cosign will create a JSON file called a "bundle". These bundles include three fields: base64Signature, cert, and rekorBundle. The desired behavior is that the verification of these bundles would: - verify the provided blob using the included signature and certificate - verify the rekorBundle SET - verify the rekorBundle payload references the given artifact. It appears that step three is not being performed, allowing "any old rekorBundle" to p...

> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.7) ### Problem Due to a parsing issue in upstream package [`masterminds/html5`](https://packagist.org/packages/masterminds/html5), malicious markup used in a sequence with special HTML comments cannot be filtered and sanitized. This allows to by-pass the cross-site scripting mechanism of `typo3/html-sanitizer`. ### Solution Update to `typo3/html-sanitizer` versions 1.0.7 or 2.0.16 that fix the problem described. ### Credits Thanks to David Klein who reported this issue, and to TYPO3 security team member Oliver Hader who fixed the issue.

Helm controller is tightly integrated with the Helm SDK. [A vulnerability](https://github.com/helm/helm/security/advisories/GHSA-7hfp-qfw3-5jxh) found in the Helm SDK allows for specific data inputs to cause high memory consumption, which in some platforms could cause the controller to panic and stop processing reconciliations. ### Impact In a shared cluster multi-tenancy environment, a tenant could create a HelmRelease that makes the controller panic, denying all other tenants from their Helm releases being reconciled. ### Credits The initial crash bug was reported by [oss-fuzz](https://github.com/google/oss-fuzz). The Flux Security team produced the first exploit and worked together with the Helm Security team to ensure that both projects were patched timely. ### For more information If you have any questions or comments about this advisory: - Open an issue in any of the affected repositories. - Contact us at the CNCF Flux Channel. ### References - https://bugs.chromium.org/p/...

### Impact In ReactPHP's HTTP server component versions below v1.7.0, when ReactPHP is processing incoming HTTP cookie values, the cookie names are url-decoded. This may lead to cookies with prefixes like `__Host-` and `__Secure-` confused with cookies that decode to such prefix, thus leading to an attacker being able to forge cookie which is supposed to be secure. See also CVE-2020-7070 and CVE-2020-8184 for more information. ### Patches * https://github.com/reactphp/http/commit/663c9a3b77b71463fa7fcb76a6676ffd16979dd6 - Fixed in [reactphp/http `v1.7.0`](https://github.com/reactphp/http/releases/tag/v1.7.0) ### Workarounds Infrastructure or DevOps can place a reverse proxy in front of the ReactPHP HTTP server to filter out any unexpected `Cookie` request headers. ### References * CVE-2020-7070, https://bugs.php.net/bug.php?id=79699 and https://github.com/php/php-src/commit/6559fe912661ca5ce5f0eeeb591d928451428ed0 * CVE-2020-8184, https://hackerone.com/reports/895727 and https:...

_This is a historical security advisory, pertaining to a vulnerability that was reported, patched, and published in 2021. It is listed here for completeness and for CVE tracking purposes._ ### Impact Due to an unnecessarily strict conditional in the code handling the first step of the SSO process, the pre-existing logic that added (and later checked) a nonce was inadvertently rendered opt-in instead of opt-out. This re-exposed a vulnerability in that a specially crafted MITM attack could theoretically take over another user account during the single sign-on process. ### Patches The issue has been fully patched as of v1.17.2. The patch commit can be found at https://github.com/NodeBB/NodeBB/commit/a2400f6baff44cb2996487bcd0cc6e2acc74b3d4 ### Workarounds Site maintainers can cherry-pick https://github.com/NodeBB/NodeBB/commit/a2400f6baff44cb2996487bcd0cc6e2acc74b3d4 into their codebase to patch the exploit. ### References * https://blogs.opera.com/security/2022/03/bug-bounty-advent...

### Impact When using `file:<location>` command and `<location>` is web URL location (http, https). mangadex-downloader will try to open and read a file in local disk for each line of website content. So far, the app only read the files and not execute it. But still, when someone reading your files without you knowing, it's very scary. ### Workarounds Unfortunately, there is no workarounds to make it safe from this issue. But i suggest you double check the url before proceed to download or update to latest version ( >= 1.7.2) ### Patches Fixed in version 1.7.2 ### Reference - https://github.com/mansuf/mangadex-downloader/blob/v1.7.1/mangadex_downloader/cli/validator.py - Commit patch: https://github.com/mansuf/mangadex-downloader/commit/439cc2825198ebc12b3310c95c39a8c7710c9b42

The PBKDF2-based JWE key management algorithms expect a JOSE Header Parameter named `p2c` ([PBES2 Count](https://www.rfc-editor.org/rfc/rfc7518.html#section-4.8.1.2)), which determines how many PBKDF2 iterations must be executed in order to derive a CEK wrapping key. The purpose of this parameter is to intentionally slow down the key derivation function in order to make password brute-force and dictionary attacks more expensive. This makes the PBES2 algorithms unsuitable for situations where the JWE is coming from an untrusted source: an adversary can intentionally pick an extremely high PBES2 Count value, that will initiate a CPU-bound computation that may take an unreasonable amount of time to finish. ### Impact Under certain conditions (see below) it is possible to have the user's environment consume unreasonable amount of CPU time. ### Affected users The impact is limited only to users utilizing the JWE decryption APIs with symmetric secrets to decrypt JWEs from untrusted part...

### Impact If a vunerable version of cruddl is used to generate a schema that uses `@flexSearchFulltext`, users of that schema may be able to inject arbitrary AQL queries that will be forwarded to and executed by ArangoDB. Schemas that do not use `@flexSearchFulltext` are not affected. The attacker needs to have `READ` permission to at least one root entity type that has `@flexSearchFulltext` enabled. ### Patches The issue has been fixed in version 3.0.2 and in version 2.7.0 of cruddl. ### Workarounds Users can temporarily remove `@flexSearchFulltext` from their schemas before they can update cruddl. ### For more information If you have any questions or comments about this advisory: * Open an issue in [cruddl](https://github.com/AEB-labs/cruddl) * Email us at [security@aeb.com](mailto:security@aeb.com)

### Impact The Rego compiler provides a (deprecated) `WithUnsafeBuiltins` function, which allows users to provide a set of built-in functions that should be deemed unsafe — and as such rejected — by the compiler if encountered in the policy compilation stage. A bypass of this protection has been found, where the use of the `with` keyword to mock such a built-in function (a feature introduced in OPA v0.40.0), isn’t taken into account by `WithUnsafeBuiltins`. The same method is exposed via `rego.UnsafeBuiltins` in the `github.com/open-policy-agent/opa/rego` package. When provided e.g. the `http.send` built-in function to `WithUnsafeBuiltins`, the following policy would still compile, and call the `http.send` function with the arguments provided to the `is_object` function when evaluated: ```rego package policy foo := is_object({ "method": "get", "url": "https://www.openpolicyagent.org" }) allow := r { r := foo with is_object as http.send } ``` Both built-in functions ...

## Impact _What kind of vulnerability is it? Who is impacted?_ This vulnerability impacts all the initialization functions on the `Heap` and `LockedHeap` types, including `Heap::new`, `Heap::init`, `Heap::init_from_slice`, and `LockedHeap::new`. It also affects multiple uses of the `Heap::extend` method. ### Initialization Functions The heap initialization methods were missing a minimum size check for the given heap size argument. This could lead to **_out-of-bound writes_** when a heap was initialized with a size smaller than `3 * size_of::<usize>` because of metadata write operations. ### `Heap::extend` This vulnerability impacts three specific uses of the `Heap::extend` method: - When calling `Heap::extend` with a size smaller than two `usize`s (e.g., 16 on `x86_64`), the size was erroneously rounded up to the minimum size, which could result in an **_out-of-bounds write_**. - Calling `Heap::extend` on an empty heap tried to construct a heap starting at address 0, which is als...