ghsa

### Summary The Comment feature has implemented a filter to prevent users from adding restricted characters, such as HTML tags. However, this filter operates on the client-side, which can be bypassed, making the application vulnerable to HTML Injection. ### Details The Comment feature implements a character filter on the client-side, this can be bypassed by directly sending a request to the endpoint. Example Request: ``` PATCH /activity/comment/3 HTTP/2 Host: directus.local { "comment": "<h1>TEST <p style=\"color:red\">HTML INJECTION</p> <a href=\"//evil.com\">Test Link</a></h1>" } ``` Example Response: ```json { "data": { "id": 3, "action": "comment", "user": "288fdccc-399a-40a1-ac63-811bf62e6a18", "timestamp": "2023-09-06T02:23:40.740Z", "ip": "10.42.0.1", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36", "collection": "directus_files", "item": "7247dda1-c386-4e7a-...

### Summary sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. ### Impact This bug impacts clients using any variation of KeylessVerifier.verify() Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. There are other mechanisms right now that mitigate this, such as the signed entry timestamp. Sigstore-java currently requires a valid signed entry timestamp. By correctly verifying the signed entry timestamp we can make certain assertions about the log signing the log entry (like the log was aware of the artifact signing event and signed it). Therefore the impact on clients...

In PyO3 0.23.0 the `PYO3_CONFIG_FILE` environment variable used to configure builds regressed such that changing the environment variable would no longer trigger PyO3 to reconfigure and recompile. In combination with workflows using tools such as `maturin` to build for multiple versions in a single build, this leads to Python wheels being compiled against the wrong Python API version. All users who distribute artefacts for multiple Python versions are encouraged to update and rebuild with PyO3 0.23.3. Affected wheels produced from PyO3 0.23.0 through 0.23.2 are highly unstable and will crash the Python interpreter in unpredictable ways.

The library breaks the safety assumptions when using unsafe API `std::slice::from_raw_parts`. First, when using the API in iterator implementation (`TempFdArrayIterator.next`), generic type could be any type, which would create and pass a misaligned pointer to the unsafe API. Second, when validating the address, the code passed the type `c_void`, which could also be any type, leading to potential uninitialized memory exposure. Two unsound usages here highlight the necessity for developers to perform type checks before doing type conversion with unsafe API. The panic caused by the misalignment causes several downstream applications (e.g., `greptimedb`) to crash when using `pprof::report::ReportBuilder::build`. This was patched in 0.14.0. The developer also suggested moving to [pprof2](https://crates.io/crates/pprof2).

During a security audit, [Radically Open Security](https://www.radicallyopensecurity.com/) discovered two vulnerabilities which allow attackers to trigger resource exhaustion vulnerabilities in `rpgp` by providing crafted messages. This affects general message parsing and decryption with symmetric keys. ### Impact Affected `rpgp` versions do not correctly set upper limits on the total reserved amount of memory when parsing long sequences of partial OpenPGP packets, which can grow to to several GiB in size. Additionally, up to 4GiB of memory is reserved for OpenPGP packets of fixed size with large length fields, even if less data is received. Depending on existing message size restrictions and available system resources, this can cause out-of-memory conditions and crash the `rpgp` process or cause other system instability through memory resource exhaustion when parsing crafted messages. Affected `rpgp` versions are susceptible to excessive memory allocation with values of up to 2TiB ...

During a security audit, [Radically Open Security](https://www.radicallyopensecurity.com/) discovered several reachable edge cases which allow an attacker to trigger `rpgp` crashes by providing crafted data. ### Impact When processing malformed input, `rpgp` can run into Rust panics which halt the program. This can happen in the following scenarios: * Parsing OpenPGP messages from binary or armor format * Decrypting OpenPGP messages via `decrypt_with_password()` * Parsing or converting public keys * Parsing signed cleartext messages from armor format * Using malformed private keys to sign or encrypt Given the affected components, we consider most attack vectors to be reachable by remote attackers during typical use cases of the `rpgp` library. The attack complexity is low since the malformed messages are generic, short, and require no victim-specific knowledge. The result is a denial-of-service impact via program termination. There is no impact to confidentiality or integrity secur...

Under certain uncommon site configurations, a bug in the CKEditor 5 module can cause some image uploads to move the entire webroot to a different location on the file system. This could be exploited by a malicious user to take down a site. The issue is mitigated by the fact that several non-default site configurations must exist simultaneously for this to occur.

The Comment module allows users to reply to comments. In certain cases, an attacker could make comment reply requests that would trigger a denial of service (DOS). Sites that do not use the Comment module are not affected.

Apache Hive Metastore (HMS) uses SerializationUtilities#deserializeObjectWithTypeInformation method when filtering and fetching partitions that is unsafe and can lead to Remote Code Execution (RCE) since it allows the deserialization of arbitrary data. In real deployments, the vulnerability can be exploited only by authenticated users/clients that were able to successfully establish a connection to the Metastore. From an API perspective any code that calls the unsafe method may be vulnerable unless it performs additional prerechecks on the input arguments.

A vulnerability in VMware Tanzu Spring LDAP allows data exposure for case sensitive comparisons.This issue affects Spring LDAP: from 2.4.0 through 2.4.3, from 3.0.0 through 3.0.9, from 3.1.0 through 3.1.7, from 3.2.0 through 3.2.7, AND all versions prior to 2.4.0. The usage of String.toLowerCase() and String.toUpperCase() has some Locale dependent exceptions that could potentially result in unintended columns from being queried Related to CVE-2024-38820 https://spring.io/security/cve-2024-38820