ghsa

When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building. Both TLS clients and TLS servers that accept client certificate are affected. This was previously reported in <https://github.com/briansmith/webpki/issues/69> and re-reported recently by Luke Malinowski. `rustls-webpki` is a fork of this crate which contains a fix for this issue and is actively maintained.

### Summary In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. It is feasible to do this at scale. An attacker would have to transfer ~1/2 as much memory it wants to occupy (2x amplification factor). The attacker can perform this attack over time as the target node’s memory will not be garbage collected. This can occur because when a signed peer record is received, only the signature validity check is performed but the sender signature is not checked. Signed peer records from randomly generated peers can be sent by a malicious actor. A target node will accept the peer record as long as the signature is valid, and then stored in the peer store. There is cleanup logic in the peer store that cleans up data when a peer disconnects, but this cleanup is never triggered for the fake peer (from which signed peer records wer...

Incorrect reallocation logic in the function [`vec_insert_bytes`](https://docs.rs/mail-internals/0.2.3/mail_internals/utils/fn.vec_insert_bytes.html) causes a use-after-free. This function does not have to be called directly to trigger the vulnerability because many methods on [`EncodingWriter`](https://docs.rs/mail-internals/0.2.3/mail_internals/encoder/struct.EncodingWriter.html) call this function internally. The mail-\* suite is unmaintained and the upstream sources have been actively vandalised. A fixed `mail-internals-ng` (and `mail-headers-ng` and `mail-core-ng`) crate has been published which fixes this, and a dependency on another unsound crate.

### During startup, an attacker that can man-in-the-middle traffic to and from NTS key exchange servers can trigger a very expensive key validation process due to a vulnerability in webpki. ### Impact This vulnerability can lead to excessive cpu usage on startup on clients configured to use NTS ### Patches Affected users are recommended to upgrade to version 0.3.7 ### References See also https://github.com/rustsec/advisory-db/blob/main/crates/rustls-webpki/RUSTSEC-2023-0053.md

## Overview `@webiny/react-rich-text-renderer` is a react component to render data coming from Webiny Headless CMS and Webiny Form Builder. The `@webiny/react-rich-text-renderer` package depends on the [editor.js](https://editorjs.io/) rich text editor to handle rich text content. The CMS stores rich text content from the `editor.js` into the database. When the `@webiny/react-rich-text-renderer` is used to render such content, it uses the `dangerouslySetInnerHTML` prop, without applying HTML sanitization. The issue arises when an actor, who in this context would specifically be a content manager with access to the CMS, inserts a malicious script as part of the user-defined input. This script is then injected and executed within the user's browser when the main page or admin page loads. ## Am I affected? You will be affected if you're running a Webiny project created prior to `5.35.0` and you're using the legacy rich text editor (which uses `editor.js` library under the hood). If you'v...

The Rust Security Response WG was notified that Cargo did not escape Cargo feature names when including them in the report generated by `cargo build --timings`. A malicious package included as a dependency may inject nearly arbitrary HTML here, potentially leading to XSS if the report is subsequently uploaded somewhere. The severity of this vulnerability is "low" for users relying on dependencies from git, local paths, or alternative registries. Users who solely depend on crates.io are unaffected. Note that **by design** Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerability in this advisory allows performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros. # Overview Rust 1.60.0 [introduced](https://blog.rust-lang.org/2022/04/07/Rust-1.60.0.html#cargo...

In Spring for Apache Kafka 3.0.9 and earlier and versions 2.9.10 and earlier, a possible deserialization attack vector existed, but only if unusual configuration was applied. An attacker would have to construct a malicious serialized object in one of the deserialization exception record headers. Specifically, an application is vulnerable when all of the following are true: * The user does not configure an ErrorHandlingDeserializer for the key and/or value of the record * The user explicitly sets container properties checkDeserExWhenKeyNull and/or checkDeserExWhenValueNull container properties to true. * The user allows untrusted sources to publish to a Kafka topic By default, these properties are false, and the container only attempts to deserialize the headers if an ErrorHandlingDeserializer is configured. The ErrorHandlingDeserializer prevents the vulnerability by removing any such malicious headers before processing the record.

### Summary The provided Minimal IAM Policy for `bastic connect` does not include `ssm:SessionDocumentAccessCheck`. This results in the ability to get a shell session on the bastion, not just the intended access for Port Forwarding. ### Details `basti connect` is designed to "securely connect to your RDS/Aurora/Elasticache/EC2 instances", using a bastion instance "with [AWS Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) port forwarding capability to make the target available on your localhost." The [Minimal IAM Policy](https://github.com/BohdanPetryshyn/basti#minimal-iam-permissions) allows port forwarding via the following statement: ``` { "Effect": "Allow", "Action": "ssm:StartSession", "Resource": [ "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost", "arn:aws:ec2:<your-region>:<your-account-id>:instance/<your-basti-instance-id>" ] } ``` This statement does no...

### Impact An attacker with the permission to perform POST requests on the /api/v1/alerts endpoint could be able to execute arbitrary JavaScript code on the users of Prometheus Alertmanager. ### Patches Users can upgrade to Alertmanager v0.2.51. ### Workarounds Users can setup a reverse proxy in front of the Alertmanager web server to forbid access to the /api/v1/alerts endpoint. ### References N/A

### Impact XWiki supports scheduled jobs that contain Groovy scripts. Currently, the job checks the content author of the job for programming right. However, modifying or adding a job script to a document doesn't modify the content author. Together with a CSRF vulnerability in the job scheduler, this can be exploited for remote code execution by an attacker with edit right on the wiki. For successful exploitation, the needs to have edit right on a document whose content has last been changed by a user with programming right. This could be the user profile for users created by admins. In this document, the attacker can create an object of class `XWiki.SchedulerJobClass` using the object editor. By setting job class to `com.xpn.xwiki.plugin.scheduler.GroovyJob`, cron expression to `0 0/5 * * * ?` and job script to `services.logging.getLogger("foo").error("Job content executed")`, the attacker can create a job. Now this job just needs to be triggered or scheduled. This can be achieved b...