ghsa

### Describe the Bug Providing a non-numeric length value to the random string generation utility will create a memory issue breaking the capability to generate random strings platform wide. This creates a denial of service situation where logged in sessions can no longer be refreshed as sessions depend on the capability to generate a random session ID. ### To Reproduce 1. Test if the endpoint is working and accessible, `GET http://localhost:8055/utils/random/string` 2. Do a bad request `GET http://localhost:8055/utils/random/string?length=foo` 3. After this all calls to `GET http://localhost:8055/utils/random/string` will return an empty string instead of a random string 4. In this error situation you'll see authentication refreshes fail for the app and api. ### Impact This counts as an unauthenticated denial of service attack vector so this impacts all unpatched instances reachable over the internet.

### Summary Exposure of HTTP basic auth credentials from repository and keyring URLs in log output ### Details There was a handful of instances where the `apko` tool was outputting error messages and log entries where HTTP basic authentication credentials were exposed for one of two reasons: 1. The`%s` verb was used to format a `url.URL` as a string, which includes un-redacted HTTP basic authentication credentials if they are included in the URL. 2. A string URL value (such as from the configuration YAML file supplied used in an apko execution) was never parsed as a URL, so there was no chance of redacting credentials in the logical flow. apko, as well as its companion library `go-apk`, have been updated to ensure URLs are parsed and redacted before being output as string values. ### PoC Create a config file like this `apko.yaml`: ```yaml contents: keyring: - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub repositories: - https://me%40example.com:supersecretpass...

## Description Affected versions of the nano-id crate incorrectly generated IDs using a reduced character set in the `nano_id::base62` and `nano_id::base58` functions. Specifically, the `base62` function used a character set of 32 symbols instead of the intended 62 symbols, and the `base58` function used a character set of 16 symbols instead of the intended 58 symbols. Additionally, the `nano_id::gen` macro is also affected when a custom character set that is not a power of 2 in size is specified. It should be noted that `nano_id::base64` is not affected by this vulnerability. ## Impact This can result in a significant reduction in entropy, making the generated IDs predictable and vulnerable to brute-force attacks when the IDs are used in security-sensitive contexts such as session tokens or unique identifiers. ## Patches The flaws were corrected in commit [a9022772b2f1ce38929b5b81eccc670ac9d3ab23](https://github.com/viz-rs/nano-id/commit/a9022772b2f1ce38929b5b81eccc670ac9d3ab23)...

### Summary iq80 Snappy performs out-of-bounds read access when uncompressing certain data, which can lead to a JVM crash. ### Details When uncompressing certain data, Snappy tries to read outside the bounds of the given byte arrays. Because Snappy uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. iq80 Snappy is not actively maintained anymore. As quick fix users can upgrade to version 0.5, but in the long term users should prefer migrating to the Snappy implementation in https://github.com/airlift/aircompressor (version 0.27 or newer). ### Impact When uncompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM.

# Details ## 1. All Imagick supported Fileformats are served without filtering The Thumbnail endpoint does not check against any filters what file formats should be served. We can transcode the image in all formats imagemagick supports. With that we can create Files that are much larger in filesize than the original. For example we can create a .txt file for all thumbnails, and we get the text representation of the image. We can demonstrate that with the pimcore demo: This Thumbnail is found on the Frontend: https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb__317__standardTeaser/11.8c64bd89.avif (12kb Filesize) We can generate a text representation by simply changing the file extension: https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb__317__standardTeaser/11.8c64bd89.txt (4.59mb Filesize) Other (large) fileformats we tested: ftxt, dip, bmp, bmp3, bmp2, farbfeld, cmyk, cmyka, ycbcr, ycbcra and many more (just check imagemagic...

javascript-deobfuscator removes common JavaScript obfuscation techniques. Crafted payloads targeting expression simplification can lead to code execution. This issue has been patched in version 1.1.0.

Due to an oversized maximum result limit, TYPO3 component Indexed Search is susceptible to a Denial of Service attack.

Failing to properly validate user input, the form component is susceptible to Arbitrary File Disclosure. A valid backend user account is needed to exploit this vulnerability. Only forms are vulnerable, which contain upload fields.

Failing to properly encode user input, the CSS styled content component is susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML or JavaScript.

All XML processing within the TYPO3 CMS are vulnerable to XEE processing. This can lead to load internal and/or external (file) content within an XML structure. Furthermore it is possible to inject arbitrary files for an XML Denial of Service attack. For more information on that topic see https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing.