David Korczynski

**Name of the Vulnerable Software and Affected Versions** Google Chrome versions prior to 148.0.7778.179 **Description** An out of bounds read in the GPU component allows a remote attacker to potentially exploit heap corruption through the use of a crafted HTML page. Heap corruption occurs when a program writes data outside the boundaries of the allocated memory on the heap, which can lead to crashes or arbitrary code execution. **Recommendations** Update to version 148.0.7778.179 or later.

**Name of the Vulnerable Software and Affected Versions** Treasure Data Fluent Bit version 1.7.1 **Description** An issue was discovered in Treasure Data Fluent Bit, where erroneous parsing in `flb pack msgpack to json format` leads to a type confusion bug. This bug interprets whatever is on the stack as msgpack maps and arrays, leading to use-after-free. An attacker can craft a specially crafted file and trick the victim into opening it using the affected software, triggering use-after-free and executing arbitrary code on the target system. **Recommendations** For Treasure Data Fluent Bit version 1.7.1, consider disabling the `flb pack msgpack to json format` function until a patch is available to prevent exploitation. Restrict access to potentially vulnerable files to minimize the risk of triggering the use-after-free bug. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** containerd versions 1.6.17 and earlier, containerd versions 1.5.17 and earlier **Description** The issue is related to the import of OCI images in containerd, where there was no limit on the number of bytes read for certain files. A maliciously crafted image with a large file could cause a denial of service. **Recommendations** Update to containerd version 1.6.18 or later to resolve the issue. Update to containerd version 1.5.18 or later to resolve the issue. As a temporary workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.

**Name of the Vulnerable Software and Affected Versions** Helm versions prior to 3.10.3 **Description** The issue concerns a NULL Pointer Dereference in the `chartutil` package that can cause a segmentation violation. This package contains a parser that loads a JSON Schema validation file, which can be used by the Helm client to validate chart values. Certain schema files can cause array data structures to be created, leading to a memory violation. This can result in a Denial of Service when the input causes a panic that cannot be recovered from. The Helm client will panic with a schema file that causes a memory violation panic, but since Helm is not a long-running service, the panic will not affect future uses of the Helm client. **Recommendations** For versions prior to 3.10.3, update to version 3.10.3 to resolve the issue. As a temporary workaround, SDK users can validate schema files that are correctly formatted before passing them to the `chartutil` functions.

**Name of the Vulnerable Software and Affected Versions** Helm versions prior to 3.10.3 **Description** Helm is a tool for managing Charts, pre-configured Kubernetes resources. The issue results in Uncontrolled Resource Consumption, leading to Denial of Service. Input to functions in the ` strvals ` package can cause a stack overflow, which cannot be recovered from in Go. Applications using functions from the ` strvals ` package in the Helm SDK can suffer a Denial of Service attack when the package panics. The ` strvals ` package contains a parser that turns strings into Go structures, and some string inputs can cause array data structures to be created, leading to a stack overflow. The Helm Client will panic with input to flags like `--set`, `--set-string`, and other value setting flags that cause a stack overflow. **Recommendations** For versions prior to 3.10.3, update to version 3.10.3 to resolve the issue. As a temporary workaround, SDK users can validate strings supplied by users to ensure they won't create large arrays causing significant memory usage before passing them to the ` strvals ` functions.

**Name of the Vulnerable Software and Affected Versions** Helm versions prior to 3.9.4 **Description** The issue is related to the strvals package in the Helm SDK, which contains a parser that turns strings into Go structures. Some string inputs can cause array data structures to be created, leading to an out of memory panic. Applications that use the strvals package to parse user-supplied input can suffer a Denial of Service when that input causes a panic that cannot be recovered from. The Helm Client will panic with input to `--set`, `--set-string`, and other value setting flags that causes an out of memory panic. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. **Recommendations** For versions prior to 3.9.4, update to version 3.9.4 to resolve the issue. As a temporary workaround, SDK users can validate strings supplied by users to ensure they won't create large arrays causing significant memory usage before passing them to the strvals functions.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 2.3.0 through 2.3.5 Argo CD versions 2.4.0 through 2.4.4 **Description** The issue is a cross-site scripting (XSS) bug that could allow an attacker to inject arbitrary JavaScript in the "/auth/callback" page in a victim's browser. This vulnerability only affects Argo CD instances with single sign-on (SSO) enabled. The exploit requires the attacker to have access to the API server's encryption key, a method to add a cookie to the victim's browser, and the ability to convince the victim to visit a malicious "/auth/callback" link. The vulnerability is classified as low severity because access to the API server's encryption key already grants a high level of access. **Recommendations** For Argo CD versions 2.3.0 through 2.3.5, update to version 2.3.6 to resolve the issue. For Argo CD versions 2.4.0 through 2.4.4, update to version 2.4.5 to resolve the issue. As a temporary workaround, consider disabling SSO until a patch is applied. Restrict access to the "/auth/callback" page to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 0.4.0 through 2.2.10 Argo CD versions 2.3.0 through 2.3.5 Argo CD versions 2.4.0 through 2.4.4 **Description** The issue is related to an improper certificate validation bug in Argo CD, which could cause it to trust a malicious OpenID Connect (OIDC) provider. This bug affects connections to OIDC providers and can be exploited by an attacker to conduct spoofing attacks. The vulnerability is related to the skipping of certificate verification when communicating with the OIDC provider, which opens Argo CD to various risks, such as a machine-in-the-middle attack. **Recommendations** For Argo CD versions 0.4.0 through 2.2.10, update to version 2.2.11 or later. For Argo CD versions 2.3.0 through 2.3.5, update to version 2.3.6 or later. For Argo CD versions 2.4.0 through 2.4.4, update to version 2.4.5 or later. As a temporary workaround for users of an external OIDC provider, consider setting the `oidc.config.rootCA` field in the `argocd-cm` ConfigMap to force certificate validation when the API server handles login flows.

**Name of the Vulnerable Software and Affected Versions** KubeEdge versions prior to 1.11.1 KubeEdge versions prior to 1.10.2 KubeEdge versions prior to 1.9.4 **Description** A large response received by the viaduct WSClient can cause a denial of service (DoS) from memory exhaustion. The entire body of the response is being read into memory, which could allow an attacker to send a request that returns a response with a large body. The consequence of the exhaustion is that the process which invokes a WSClient will be in a denial of service. This issue affects users who are authenticated to the edge side and connect to `cloudhub` from the edge side through WebSocket protocol. **Recommendations** For versions prior to 1.11.1, update to version 1.11.1 or later. For versions prior to 1.10.2, update to version 1.10.2 or later. For versions prior to 1.9.4, update to version 1.9.4 or later. As a temporary workaround, consider restricting access to the `cloudhub` through WebSocket protocol to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** KubeEdge versions prior to 1.11.1 KubeEdge versions prior to 1.10.2 KubeEdge versions prior to 1.9.4 **Description** The ServiceBus server on the edge side may be susceptible to a DoS attack if an HTTP request containing a very large Body is sent to it. It is possible for the node to be exhausted of memory, causing a denial of service for other services on the node, such as other containers. This issue can be exploited by malicious apps that have access to send HTTP requests to localhost, but only when the `ServiceBus` module is enabled in the config file `edgecore.yaml`. **Recommendations** For versions prior to 1.11.1, update to version 1.11.1 or later. For versions prior to 1.10.2, update to version 1.10.2 or later. For versions prior to 1.9.4, update to version 1.9.4 or later. As a temporary workaround, disable the `ServiceBus` module in the config file `edgecore.yaml`.

**Name of the Vulnerable Software and Affected Versions** KubeEdge versions prior to 1.11.1 KubeEdge versions prior to 1.10.2 KubeEdge versions prior to 1.9.4 **Description** KubeEdge is an open source system for extending native containerized application orchestration capabilities to hosts at Edge. Several endpoints in the Cloud AdmissionController, including "/devicemodels", "/rules", "/ruleendpoints", and "/offlinemigration", may be susceptible to a DoS attack if an HTTP request containing a very large Body is sent to it. The consequence of the exhaustion is that the Cloud AdmissionController will be in denial of service. Only an authenticated user can cause this issue. **Recommendations** Update to KubeEdge version 1.11.1 or later to resolve the issue. Update to KubeEdge version 1.10.2 or later to resolve the issue. Update to KubeEdge version 1.9.4 or later to resolve the issue. As a temporary workaround, consider restricting access to the vulnerable endpoints in the Cloud AdmissionController until a patch is available. Avoid sending HTTP requests with very large Bodies to the Cloud AdmissionController until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** KubeEdge versions prior to 1.11.1 KubeEdge versions prior to 1.10.2 KubeEdge versions prior to 1.9.4 **Description** EdgeCore may be susceptible to a DoS attack on CloudHub if an attacker sends a well-crafted HTTP request to "/edge.crt". If the request has a very large body, it can crash the HTTP service through a memory exhaustion vector. The request body is being read into memory, and a body larger than the available memory can lead to a successful attack. Only authorized users can perform this attack, as the request must pass through authorization. The consequence of the exhaustion is that CloudHub will be in denial of service. This issue affects KubeEdge only when the CloudHub module is enabled in the file `cloudcore.yaml`. **Recommendations** For versions prior to 1.11.1, update to version 1.11.1 or later. For versions prior to 1.10.2, update to version 1.10.2 or later. For versions prior to 1.9.4, update to version 1.9.4 or later. As a temporary workaround, disable the CloudHub switch in the config file `cloudcore.yaml`.

**Name of the Vulnerable Software and Affected Versions** KubeEdge versions prior to 1.11.1 KubeEdge versions prior to 1.10.2 KubeEdge versions prior to 1.9.4 **Description** The CloudCore Router in KubeEdge does not impose a limit on the size of responses to requests made by the REST handler, allowing an attacker to make a request that will return an HTTP response with a large body and cause a denial of service. This can occur when the `router` module is enabled in the config file `cloudcore.yaml`. Only an authenticated user of the cloud can make an attack. The consequence of the exhaustion is that CloudCore will be in a denial of service. **Recommendations** For versions prior to 1.11.1, update to version 1.11.1 or later. For versions prior to 1.10.2, update to version 1.10.2 or later. For versions prior to 1.9.4, update to version 1.9.4 or later. As a temporary workaround, disable the `router` module in the config file `cloudcore.yaml` by setting `enable` to `false`.

**Name of the Vulnerable Software and Affected Versions** KubeEdge versions prior to 1.11.1 KubeEdge versions prior to 1.10.2 KubeEdge versions prior to 1.9.4 **Description** The Cloud Stream server and the Edge Stream server read the entire message into memory without imposing a limit on the size of this message. An attacker can exploit this by sending a large message to exhaust memory and cause a denial of service. The Cloud Stream server and the Edge Stream server are under denial of service attack in this case. The consequence of the exhaustion is that the CloudCore and EdgeCore will be in a denial of service. Only an authenticated user can cause this issue. It will be affected only when users enable `cloudStream` module in the config file `cloudcore.yaml` and enable `edgeStream` module in the config file `edgecore.yaml`. **Recommendations** For versions prior to 1.11.1, update to version 1.11.1 or later. For versions prior to 1.10.2, update to version 1.10.2 or later. For versions prior to 1.9.4, update to version 1.9.4 or later. As a temporary workaround, disable the `cloudStream` module in the config file `cloudcore.yaml` and disable the `edgeStream` module in the config file `edgecore.yaml`, then restart the cloudcore and edgecore processes.

**Name of the Vulnerable Software and Affected Versions** KubeEdge versions prior to 1.11.0 KubeEdge versions prior to 1.10.1 KubeEdge versions prior to 1.9.3 **Description** A malicious message can crash CloudCore by triggering a nil-pointer dereference in the UDS Server. The attack is limited to the local host network and requires an attacker to be an authenticated user of the Cloud. This issue only affects users who have turned on the unixsocket switch in the config file cloudcore.yaml. **Recommendations** For versions prior to 1.11.0, update to version 1.11.0 to resolve the issue. For versions prior to 1.10.1, update to version 1.10.1 to resolve the issue. For versions prior to 1.9.3, update to version 1.9.3 to resolve the issue. As a temporary workaround, consider disabling the unixsocket switch of CloudHub in the config file cloudcore.yaml.

**Name of the Vulnerable Software and Affected Versions** KubeEdge versions prior to 1.11.0 KubeEdge versions prior to 1.10.1 KubeEdge versions prior to 1.9.3 **Description** A malicious message response from KubeEdge can crash the CSI Driver controller server by triggering a nil-pointer dereference panic, resulting in a denial of service. This issue affects KubeEdge, which extends native containerized application orchestration and device management to hosts at the Edge. An attacker would need to be an authenticated user of the Cloud and launch the `csidriver` to potentially exploit this issue. **Recommendations** For versions prior to 1.11.0, update to version 1.11.0 to resolve the issue. For versions prior to 1.10.1, update to version 1.10.1 to resolve the issue. For versions prior to 1.9.3, update to version 1.9.3 to resolve the issue. As a temporary workaround, consider restricting access to the CSI Driver controller server until a patch is applied. At the moment, there are no other workarounds available.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 1.0.0 through 2.4.0 Argo CD versions 2.1.0 through 2.1.15 Argo CD versions 2.2.0 through 2.2.9 Argo CD versions 2.3.0 through 2.3.4 **Description** Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. The issue is related to a cross-site scripting (XSS) bug, allowing a malicious user to inject a `javascript:` link in the UI. When clicked by a victim user, the script will execute with the victim's permissions, up to and including admin. This could enable the creation, modification, and deletion of Kubernetes resources. **Recommendations** For versions prior to 2.1.16, upgrade to version 2.1.16 or later. For versions prior to 2.2.10, upgrade to version 2.2.10 or later. For versions prior to 2.3.5, upgrade to version 2.3.5 or later. For versions prior to 2.4.1, upgrade to version 2.4.1 or later. As a temporary workaround, consider avoiding clicking external links presented in the UI and carefully limiting who has permissions to edit resource manifests.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 0.11.0 through 2.4.0 Argo CD versions 2.1.0 through 2.1.15 Argo CD versions 2.2.0 through 2.2.9 Argo CD versions 2.3.0 through 2.3.4 **Description** The issue is related to the use of insufficiently random values in parameters in Oauth2/OIDC login flows, making it possible for an attacker to gain admin access to Argo CD. The attacks are difficult to accomplish but can have a high impact. The vulnerabilities are due to the use of a relatively-predictable seed in a non-cryptographically-secure pseudo-random number generator, and in some cases, using too short a value made the entropy even less sufficient. The vulnerable parameters include the `state` parameter, `code verifier` parameter, and `nonce` parameter. **Recommendations** For Argo CD versions 0.11.0 through 2.1.15, update to version 2.1.16 or later. For Argo CD versions 2.2.0 through 2.2.9, update to version 2.2.10 or later. For Argo CD versions 2.3.0 through 2.3.4, update to version 2.3.5 or later. For Argo CD versions 2.4.0 and earlier, update to version 2.4.1 or later. As a temporary workaround, consider restricting access to the Oauth2/OIDC login flows until a patch is applied.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 0.7.0 and later Argo CD versions prior to 2.1.16 Argo CD versions prior to 2.2.10 Argo CD versions prior to 2.3.5 Argo CD versions prior to 2.4.1 **Description** The issue is related to an uncontrolled memory consumption bug in Argo CD, allowing an authorized malicious user to crash the repo-server service, resulting in a Denial of Service. The attacker must be an authenticated Argo CD user authorized to deploy Applications from a repository which contains (or can be made to contain) a large file. **Recommendations** For versions 0.7.0 and later, upgrade to version 2.1.16 or later. For versions prior to 2.1.16, upgrade to version 2.1.16 or later. For versions prior to 2.2.10, upgrade to version 2.2.10 or later. For versions prior to 2.3.5, upgrade to version 2.3.5 or later. For versions prior to 2.4.1, upgrade to version 2.4.1 or later. As a temporary workaround, consider limiting who can configure repos, which repos are allowed, and who has push access to those repos. After upgrading, tune the `reposerver.max.combined.directory.manifests.size` config parameter to cap the maximum total file size of .yaml/.yml/.json files in directory-type Applications.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 1.3.0 through 2.4.0 Argo CD versions 2.1.0 through 2.1.15 Argo CD versions 2.2.0 through 2.2.9 Argo CD versions 2.3.0 through 2.3.4 **Description** The issue is related to a symlink following bug in Argo CD, allowing a malicious user with repository write access to leak sensitive YAML files from Argo CD's repo-server. A malicious Argo CD user with write access for a repository which is (or may be) used in a Helm-type Application may commit a symlink which points to an out-of-bounds file. If the target file is a valid YAML file, the attacker can read the contents of that file. Sensitive files which could be leaked include manifest files from other Applications' source repositories (potentially decrypted files, if you are using a decryption plugin) or any YAML-formatted secrets which have been mounted as files on the repo-server. **Recommendations** For versions 1.3.0 through 2.1.15, update to version 2.1.16 or later. For versions 2.2.0 through 2.2.9, update to version 2.2.10 or later. For versions 2.3.0 through 2.3.4, update to version 2.3.5 or later. For versions 2.4.0 and earlier, update to version 2.4.1 or later. As a temporary workaround, consider disabling the Helm config management tool if you are using a version >=v2.3.0 and do not have any Helm-type Applications. Avoid mounting YAML-formatted secrets as files on the repo-server. Limit who has push access to manifest repositories. Limit who is allowed to configure new source repositories.