ghsa

> ### 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...

### Impact Some resources are missing a check for inactive (not yet activated or disabled) users in XWiki, including the REST service: so a disabled user can enable themselves using a REST call. On the same way some resources handler created by extensions are not protected by default: so an inactive users could perform actions for such extensions. This issue exists since at least version 1.1 of XWiki for instance configured with the email activation required for new users. Now it's more critical for newer versions (>= 11.3RC1) since we provided the capability to disable user without deleting them, and we encouraged using that feature. ### Patches This issue has been patched in XWiki 14.3RC1 and XWiki 13.10.5. ### Workarounds There is no workaround for this other than upgrading XWiki. ### References * https://jira.xwiki.org/browse/XWIKI-19559 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.x...