ghsa

### 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 [security@cilium.io](mailto:security@cilium.io)

### 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 bounty@ethereum.org, 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...

### Impact A bug was found in runc where `runc exec --cap` executed processes with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. ### Patches This bug has been fixed in runc 1.1.2. Users should update to this version as soon as possible. This fix changes `runc exec --cap` behavior such that the additional capabilities granted to the process being executed (as specified via `--cap` arguments) do not include inheritable capabilities. In addition, `runc spec` is changed to not set any inheritable capabilities in the created example OCI spec (`config.json`) file. ### Credits The opencontainers project would like to thank [Andrew G. Morgan](https://github.com...

### Impact The implementation of [`tf.raw_ops.TensorSummaryV2`](https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/core/kernels/summary_tensor_op.cc#L33-L58) does not fully validate the input arguments. This results in a `CHECK`-failure which can be used to trigger a denial of service attack: ```python import numpy as np import tensorflow as tf tf.raw_ops.TensorSummaryV2( tag=np.array('test'), tensor=np.array(3), serialized_summary_metadata=tf.io.encode_base64(np.empty((0)))) ``` The code assumes `axis` is a scalar but there is no validation for this. ```cc const Tensor& serialized_summary_metadata_tensor = c->input(2); // ... ParseFromTString(serialized_summary_metadata_tensor.scalar<tstring>()(), v->mutable_metadata()); ``` ### Patches We have patched the issue in GitHub commit [290bb05c80c327ed74fae1d089f1001b1e2a4ef7](https://github.com/tensorflow/tensorflow/commit/290bb05c80c327ed74fae1d089...