ghsa

WSO2 Registry has been identified as vulnerable due to improper output encoding, a Stored Cross Site Scripting (XSS) attack can be carried out by an attacker injecting a malicious payload into the Registry feature of the Management Console.

An issue was discovered in free5GC version 3.3.0, allows remote attackers to execute arbitrary code and cause a denial of service (DoS) on AMF component via crafted NGAP message.

### Impact Within the scope of requests to S3 object keys and/or prefixes containing a Unix double-dot, a URI path traversal is possible. The issue exists in the`buildEndpoint` method in the `RestSerializer` component of the AWS SDK for PHP v3 prior to 3.288.1. The `buildEndpoint` method relies on the Guzzle Psr7 `UriResolver` utility, which strips dot segments from the request path in accordance with RFC 3986. Under certain conditions, this could lead to an arbitrary object being accessed. Versions of the AWS SDK for PHP v3 before 3.288.1 are affected by this issue. ### Patches Upgrade to the AWS SDK for PHP >= 3.288.1, if you are on version < 3.288.1. ### References RFC 3986 - [https://datatracker.ietf.org/doc/html/rfc3986](https://datatracker.ietf.org/doc/html/rfc3986#section-5.2.4) ### For more information If you have any questions or comments about this advisory, please contact [AWS's Security team](mailto:[email protected]).

Affected versions of this crate did not validate the size of buffers when attempting to decode messages. This allows an attacker to trigger a panic by sending a UDP datagram with a 1 byte payload over network. This flaw was corrected by validating the size of the buffers before attempting to decode the message.

automad up to 1.10.9 is vulnerable to an authenticated blind server-side request forgery in `importUrl` as the `import` function on the `FileController.php` file was not properly validating the value of the `importUrl` argument. This issue may allow attackers to perform a port scan against the local environment or abuse some service.

A vulnerability was found in automad up to 1.10.9. This affects the function upload of the file `FileCollectionController.php` of the component `Content Type Handler`. The manipulation leads to unrestricted upload. The attack may be launched remotely and an exploit has been disclosed publicly.

automad up to 1.10.9 does not implement anti-CSRF tokens by default, making it vulnerable Cross-Site Request Forgery (CSRF). An attacker may exploit this vulnerability to force an admin into creating or deleting users. An exploit has been disclosed publicly.

An issue was found in the redirect_uri validation logic that allows for a bypass of otherwise explicitly allowed hosts. The problem arises in the verifyRedirectUri method, which attempts to enforce rules on user-controllable input, but essentially causes a desynchronization in how Keycloak and browsers interpret URLs. Keycloak, for example, receives "[www%2ekeycloak%2eorg%2fapp%2f:[email protected]](https://www%2ekeycloak%2eorg%2fapp%2f:[email protected]/)" and thinks the authority to be keycloak.org when it is actually example.com. This happens because the validation logic is performed on a URL decoded version, which no longer represents the original input. ### Acknowledgements Karel Knibbe

Older versions of `gradio` contained a vulnerability in the `/file` route which made them susceptible to file traversal attacks in which an attacker could access arbitrary files on a machine running a Gradio app with a public URL (e.g. if the demo was created with `share=True`, or on Hugging Face Spaces) if they knew the path of files to look for. This was not possible through regular URLs passed into a browser, but it was possible through the use of programmatic tools such as `curl` with the `--pass-as-is` flag. Furthermore, the `/file` route in Gradio apps also contained a vulnerability that made it possible to use it for SSRF attacks. Both of these vulnerabilities have been fixed in `gradio==4.11.0`

Affected versions allocate memory using the alignment of `usize` and write data to it of type `u64`, without using `core::ptr::write_unaligned`. In platforms with sub-64bit alignment for `usize` (including wasm32 and x86) these writes are insufficiently aligned some of the time. If using an ordinary optimized standard library, the bug exhibits Undefined Behavior so may or may not behave in any sensible way, depending on optimization settings and hardware and other things. If using a Rust standard library built with debug assertions enabled, the bug manifests deterministically in a crash (non-unwinding panic) saying _"ptr::write requires that the pointer argument is aligned and non-null"_. No 64-bit platform is impacted by the bug. The flaw was corrected by allocating with adequately high alignment on all platforms.