ghsa

### Impact A buffer that was used for inbound network traffic had no upper limit. Pion DTLS would buffer all network traffic from the remote user until the handshake completes or times out. An attacker could exploit this to cause excessive memory usage. ### Patches Upgrade to Pion DTLS v2.1.4 ### Workarounds No workarounds available, upgrade to Pion DTLS v2.1.4 ### References Thank you to [Juho Nurminen](https://github.com/jupenur) and the Mattermost team for discovering and reporting this. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Pion DTLS](http://github.com/pion/dtls) * Email us at [[email protected]](mailto:[email protected])

### Impact The primary use case for Smokescreen is to prevent server-side request forgery (SSRF) attacks in which external attackers leverage the behavior of applications to connect to or scan internal infrastructure. Smokescreen also offers an option to deny access to additional (e.g., external) URLs by way of a deny list. There was an issue in Smokescreen that made it possible to bypass the deny list feature by surrounding the hostname with square brackets (e.g. `[example.com]`). ### Recommendation Upgrade Smokescreen to version 0.0.4 or later. ### Acknowledgements Thanks to [Axel Chong](https://github.com/haxatron) for reporting the issue. ### For more information Email us at [email protected]

### Impact We found that this vulnerability is present when the developer is implementing an OAuth 1 provider (by extension, it means Twitter, which is the only built-in provider using OAuth 1), but **upgrading** is **still recommended**. `next-auth` v3 users before version 3.29.3 are impacted. (We recommend upgrading to v4, as v3 is considered unmaintained. See our [migration guide](https://next-auth.js.org/getting-started/upgrade-v4)) `next-auth` v4 users before version 4.3.3 are impacted. ### Patches We've released patches for this vulnerability in: - v3 - `3.29.3` - v4 - `4.3.3` You can do: ```sh npm i next-auth@latest ``` or ```sh yarn add next-auth@latest ``` or ```sh pnpm add next-auth@latest ``` (This will update to the latest v4 version, but you can change `latest` to `3` if you want to stay on v3.) ### Workarounds If you are not able to upgrade for any reason, you can add the following configuration to your `callbacks` option: ```ts // async redirect(url, b...

### Impact Token comparison was not constant time, and could theorically be used to guess value of an TOTP token, and thus reuse it in the same time window. The attacker would have to know the password beforehand nonetheless. ### Patches Library now used constant-time comparison. ### Workarounds No. ### For more information If you have any questions or comments about this advisory: * Open an issue in [totp-rs](https://github.com/constantoine/totp-rs) * Email us at [[email protected]](mailto:[email protected])

### Impact If an attacker is able to perform a container escape of a container running as root on a host where Cilium is installed, the attacker can leverage Cilium's Kubernetes service account to gain access to cluster privileges that are more permissive than what is minimally required to operate Cilium. In affected releases, this service account had access to modify and delete `Pod` and `Node` resources. ### Patches The problem has been fixed and is available on versions >=1.9.16, >=1.10.11, >=1.11.5 ### Workarounds There are no workarounds available. ### Acknowledgements The Cilium community has worked together with members of Isovalent, Amazon and Palo Alto Networks to prepare these mitigations. Special thanks to Micah Hausler, Robert Clark, Yuval Avrahami, and Shaul Ben Hai for their cooperation. ### For more information If you have any questions or comments about this advisory: Email us at [[email protected]](mailto:[email protected])

### Impact Users with host file system access on a node and the privileges to run as group ID 1000 can gain access to the per node API of Cilium via Unix domain socket on the host where Cilium is running. If a malicious user is able to gain unprivileged access to a user corresponding to this group, then they can leverage this access to compromise the integrity as well as system availability on that host. Operating Systems that have unprivileged users **not** belonging the group ID 1000 are **not** affected by this vulnerability. Best practices for managing the secure deployment of Kubernetes clusters will typically limit the ability for a malicious user to deploy pods with access to this group or to access the host filesystem, and limit user access to the nodes for users belonging to this group. These best practices include (but are not limited to) enforcing Admission Control policies to limit the configuration of Kubernetes Pod [hostPath](https://kubernetes.io/docs/concepts/storage/...

We've discovered a vulnerability in which attackers could forge HTTP requests to manipulate the `charm` data directory to access or delete anything on the server. This has been patched in https://github.com/charmbracelet/charm/commit/3c90668f955c7ce5ef721e4fc9faee7053232fd3 and is available in release [v0.12.1](https://github.com/charmbracelet/charm/releases/tag/v0.12.1). We recommend that all users running self-hosted `charm` instances update immediately. This vulnerability was found in-house and we haven't been notified of any potential exploiters. ### Additional notes * Encrypted user data uploaded to the Charm server is safe as Charm servers cannot decrypt user data. This includes filenames, paths, and all key-value data. * Users running the official Charm [Docker images](https://github.com/charmbracelet/charm/blob/main/docker.md) are at minimal risk because the exploit is limited to the containerized filesystem. ### For more information If you have any questions or comments a...

### Impact A vulnerable node, if configured to use high verbosity logging, can be made to crash when handling specially crafted p2p messages sent from an attacker node. ### Patches The following PR addresses the problem: https://github.com/ethereum/go-ethereum/pull/24507 ### Workarounds Aside from applying the PR linked above, setting loglevel to default level (`INFO`) makes the node not vulnerable to this attack. ### Credits This bug was reported by `nrv` via [email protected], who has gracefully requested that the bounty rewards be donated to Médecins sans frontières. ### For more information If you have any questions or comments about this advisory: * Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum)

### Impact [go-tuf](https://github.com/theupdateframework/go-tuf) does not correctly implement the [client workflow](https://theupdateframework.github.io/specification/v1.0.28/index.html#detailed-client-workflow) for updating the metadata files for roles other than the root role. Specifically, checks for rollback attacks are not implemented correctly meaning an attacker can cause clients to install software that is older than the software which the client previously knew to be available, and may include software with known vulnerabilities. In more detail, the client code of go-tuf has several issues in regards to preventing rollback attacks: 1. It does not take into account the content of any previously trusted metadata, if available, before proceeding with updating roles other than the root role (i.e., steps 5.4.3.1 and 5.5.5 of the detailed client workflow). This means that any form of version verification done on the newly-downloaded metadata is made using the default value of zer...

### Overview In versions before and including `11.32.2`, when the “additional signup fields” feature [is configured](https://github.com/auth0/lock#additional-sign-up-fields), a malicious actor can inject invalidated HTML code into these additional fields, which is then stored in the service `user_metdata` payload (using the `name` property). Verification emails, when applicable, are generated using this metadata. It is therefor possible for an actor to craft a malicious link by injecting HTML, which is then rendered as the recipient's name within the delivered email template. ### Am I affected? You are impacted by this vulnerability if you are using `auth0-lock` version `11.32.2` or lower and are using the “additional signup fields” feature in your application. ### How to fix that? Upgrade to version `11.33.0`. ### Will this update impact my users? Additional signup fields that have been added to the signup tab on Lock will have HTML tags stripped from user input from version `11....