ghsa

### Problem When users reset their password using the corresponding password recovery functionality, existing sessions for that particular user account were not revoked. This applied to both frontend user sessions and backend user sessions. ### Solution Update to TYPO3 versions 10.4.33, 11.5.20, 12.1.1 that fix the problem described above. ### References * [TYPO3-CORE-SA-2022-014](https://typo3.org/security/advisory/typo3-core-sa-2022-014)

### Problem Restricting frontend login to specific users, organized in different storage folders (partitions), can be bypassed. A potential attacker might use this ambiguity in usernames to get access to a different account - however, credentials must be known to the adversary. ### Solution Update to TYPO3 versions 8.7.49 ELTS, 9.5.38 ELTS, 10.4.33, 11.5.20, 12.1.1 that fix the problem described above. ### References * [TYPO3-CORE-SA-2022-013](https://typo3.org/security/advisory/typo3-core-sa-2022-013)

### Problem Requesting invalid or non-existing resources via HTTP triggers the page error handler, which again could retrieve content to be shown as an error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded. This vulnerability is very similar, but not identical, to the one described in [TYPO3-CORE-SA-2021-005](https://typo3.org/security/advisory/typo3-core-sa-2021-005) (CVE-2021-21359). ### Solution Update to TYPO3 versions 9.5.38 ELTS, 10.4.33 or 11.5.20 that fix the problem described above. ### References * [TYPO3-CORE-SA-2022-012](https://typo3.org/security/advisory/typo3-core-sa-2022-012)

### Problem Due to a parsing issue in the upstream package [`masterminds/html5`](https://packagist.org/packages/masterminds/html5), malicious markup used in a sequence with special HTML CDATA sections cannot be filtered and sanitized. This allows bypassing the cross-site scripting mechanism of [`typo3/html-sanitizer`](https://packagist.org/packages/typo3/html-sanitizer). Besides that, the upstream package `masterminds/html5` provides HTML raw text elements (`script`, `style`, `noframes`, `noembed` and `iframe`) as DOMText nodes, which were not processed and sanitized further. None of the mentioned elements were defined in the default builder configuration, that's why only custom behaviors, using one of those tag names, were vulnerable to cross-site scripting. ### Solution Update to `typo3/html-sanitizer` versions 1.5.0 or 2.1.1 that fix the problem described.

A vulnerability in Apache CXF before versions 3.5.5 and 3.4.10 allows an attacker to perform a remote directory listing or code exfiltration. The vulnerability only applies when the CXFServlet is configured with both the static-resources-list and redirect-query-check attributes. These attributes are not supposed to be used together, and so the vulnerability can only arise if the CXF service is misconfigured.

A stack overflow in the org.json.JSONTokener.nextValue::JSONTokener.java component of hutool-json v5.8.10 allows attackers to cause a Denial of Service (DoS) via crafted JSON or XML data.

A stack overflow in the XML.toJSONObject component of hutool-json v5.8.10 allows attackers to cause a Denial of Service (DoS) via crafted JSON or XML data.

hutool-json v5.8.10 was discovered to contain an out of memory error. This issue is similar to CVE-2022-45690.

### Impact The linux-loader crate used the offsets and sizes provided in the ELF headers to determine the offsets to read from. If those offsets pointed beyond the end of the file this could lead to an infinite loop. Virtual Machine Monitors using the `linux-loader` crate could enter an infinite loop if the ELF header of the kernel they are loading was modified in a malicious manner. ### Patches The issue has been addressed in 0.8.1 ### Workarounds The issue can be mitigated by ensuring that only trusted kernel images are loaded or by verifying that the headers to not point beyond the end of the file. ### References See: https://github.com/rust-vmm/linux-loader/pull/125

A problem with Candy Machine V2 allow minting NFTs to an arbitrary collection due to a missing check. Here is a description of the exploit: Details: Here is the tx/ix to exploit: Transaction: Ix 1: candy_machine v2, mint_nft, passing in empty metadata -1 Ix 2: custom handler, 0 cpi A --> token_metadata create_metadata_account, creates NFT cpi B --> candy_machine v2, set_collection_during_mint Ix 1 passes our first check for empty metadata, but eventually will hit a bot tax and return Ok. We do have a CPI check in this function but even if we hit that or moved it to the top, it returns Ok as a bot tax and still enables the issue. Ix 2, cpi A is Ok and mints an arbitrary NFT. Ix 2, cpi B checks the previous instruction using index_relative_to_current-1. This turns out to be Ix 1 which was Ok, so then your newly minted arbitrary NFT is successfully added to the collection. Conclusion: Candy machine could be out of NFTs and it still works. If the CM is closed, (we think?) it doesn'...