ghsa

### Impact A Mass assignment vulnerability was found allowing a non-admin user to escalate privileges to admin user. ### Patches Issue is patched in 0.17.1, and fixed in 0.18.6+. If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later. ### Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server. ### References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery

### Impact An IDOR vulnerability was found in the user update function. By specifying another user's username it is possible to update the other user's password. ### Patches Issue is patched in 0.17.1, and fixed in 0.18.6+. If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later. ### Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server. ### References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery

### Impact Hardcoded DNS key usage has been found in Netmaker allowing unauth users to interact with DNS API endpoints. ### Patches Issue is patched in 0.17.1, and fixed in 0.18.6+. If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later. ### Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server. ### References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery

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.