ghsa

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

Firepad through 1.5.11 allows remote attackers, who have knowledge of a pad ID, to retrieve both the current text of a document and all content that has previously been pasted into the document. NOTE: in several similar products, this is the intentional behavior for anyone who knows the full document ID and corresponding URL. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Affected versions use deno_core releases that expose `Deno.core.ops.op_panic` to the JS runtime in the base core This function when called triggers a manual panic in the thread containing the runtime. It can be fixed by stubbing out the exposed op: ```javascript Deno.core.ops.op_panic = (msg) => { throw new Error(msg) }; ```

Affected versions use deno_core releases that expose `Deno.core.ops.op_panic` to the JS runtime in the base core This function when called triggers a manual panic in the thread containing the runtime, breaking sandboxing It can be fixed by stubbing out the exposed op: ```javascript Deno.core.ops.op_panic = (msg) => { throw new Error(msg) }; ```

When given a valid UTF8 string "ö\x1b😀", the function in crates/anstream/src/adapter/strip.rs will be confused. The UTF8 bytes are \xc3\xb6 then \x1b then \xf0\x9f\x98\x80. When looping over "non-printable bytes" \x1b\xf0 will be considered as some non-printable sequence. This will produce a broken str from the incorrectly segmented bytes via str::from_utf8_unchecked, and that should never happen. Full credit goes to @Ralith who reviewed this code and asked @burakemir to follow up.

The borsh serialization of the HashMap did not follow the borsh specification. It potentially produced non-canonical encodings dependent on insertion order. It also did not perform canonicty checks on decoding. This can result in consensus splits and cause equivalent objects to be considered distinct. This was patched in 0.15.1.