ghsa

### 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....

### Impact The malicious user is able to upload a crafted SVG file as the issue attachment to archive XSS. All installations [allow uploading SVG (`text/xml`) files as issue attachments (non-default)](https://github.com/gogs/gogs/blob/e51e01683408e10b3dcd2ace65e259ca7f0fd61b/conf/app.ini#L283-L284) are affected. ### Patches Correctly setting the Content Security Policy for the serving endpoint. Users should upgrade to 0.12.7 or the latest 0.13.0+dev. ### Workarounds [Disable uploading SVG files (`text/xml`) as issue attachments](https://github.com/gogs/gogs/blob/e51e01683408e10b3dcd2ace65e259ca7f0fd61b/conf/app.ini#L283-L284). ### References https://huntr.dev/bounties/34a12146-3a5d-4efc-a0f8-7a3ae04b198d/ ### For more information If you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/6919.

### Impact A critical vulnerability has been discovered in Argo CD which would allow unauthenticated users to impersonate as any Argo CD user or role, including the `admin` user, by sending a specifically crafted JSON Web Token (JWT) along with the request. In order for this vulnerability to be exploited, [anonymous access](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#anonymous-access) to the Argo CD instance must have been enabled. In a default Argo CD installation, anonymous access is disabled. To find out if anonymous access is enabled in your instance, please see the *Workarounds* section of this advisory below. The vulnerability can be exploited to impersonate as any user or role, including the built-in `admin` account regardless of whether that account is enabled or disabled. Also, the attacker does not need an account on the Argo CD instance in order to exploit this. If anonymous access to the instance is enabled, an attacker can: * Escalate their privile...