Jake-Ciolek

**Name of the Vulnerable Software and Affected Versions** Spinnaker versions prior to 2025.4.1 Spinnaker versions prior to 2025.3.1 Spinnaker versions prior to 2025.2.4 Spinnaker version 2026.0.0 **Description** Spinnaker updated the URL validation logic for user input to sanitize URLs for clouddriver. However, Java URL objects do not correctly handle underscores during parsing, leading to a bypass of a previous issue. This impacts both clouddriver and Orca fromUrl expression handling. The issue stems from a flaw in how Java URL objects process underscores within URLs, effectively circumventing the intended URL validation. **Recommendations** Versions prior to 2025.4.1 should be updated to version 2025.4.1 or later. Versions prior to 2025.3.1 should be updated to version 2025.3.1 or later. Versions prior to 2025.2.4 should be updated to version 2025.2.4 or later. Version 2026.0.0 contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 1.2.0 through 1.8.7 Argo CD versions 2.0.0-rc1 through 2.14.19 Argo CD versions 3.0.0-rc1 through 3.2.0-rc1 Argo CD version 3.1.7 Argo CD version 3.0.18 **Description** Argo CD is susceptible to denial of service through malicious API requests. Specifically, when a `webhook.bitbucketserver.secret` is not configured, the `/api/webhook` endpoint crashes upon receiving a malformed Bitbucket Server payload where the `repository.links.clone` field is not an array. A single unauthenticated request can cause the API server to enter a CrashLoopBackOff state, and targeting all replicas can result in a complete API outage. The issue stems from an unsafe type assertion within the `webhook.go` file, which panics when the expected array type is not met. A proof-of-concept (PoC) demonstrates that sending a crafted JSON payload to the `/api/webhook` endpoint can trigger this panic and crash the server. **Recommendations** For Argo CD versions 1.2.0 through 1.8.7, configure a `webhook.bitbucketserver.secret` to ensure only trusted parties can invoke the webhook handler. For Argo CD versions 2.0.0-rc1 through 2.14.19, configure a `webhook.bitbucketserver.secret` to ensure only trusted parties can invoke the webhook handler. For Argo CD versions 3.0.0-rc1 through 3.2.0-rc1, configure a `webhook.bitbucketserver.secret` to ensure only trusted parties can invoke the webhook handler. For Argo CD version 3.1.7, configure a `webhook.bitbucketserver.secret` to ensure only trusted parties can invoke the webhook handler. For Argo CD version 3.0.18, configure a `webhook.bitbucketserver.secret` to ensure only trusted parties can invoke the webhook handler. If Bitbucket Server is not used, set the `webhook.bitbucketserver.secret` to a long, random value to effectively disable webhook handling for Bitbucket Server payloads.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 2.9.0-rc1 through 2.14.19 Argo CD versions 3.0.0-rc1 through 3.2.0-rc1 Argo CD version 3.1.6 Argo CD version 3.0.17 **Description** Argo CD, a declarative GitOps continuous delivery tool for Kubernetes, is susceptible to a denial-of-service issue. When the `webhook.azuredevops.username` and `webhook.azuredevops.password` are not set in the default configuration, the `/api/webhook` endpoint crashes the entire `argocd-server` process upon receiving an Azure DevOps Push event with an empty `resource.refUpdates` JSON array. This occurs because the code attempts to access the first element (`[0]`) of the `resource.refUpdates` slice without verifying its length, leading to an index-out-of-range panic. A single unauthenticated HTTP POST request to the `/api/webhook` endpoint is sufficient to terminate the process. The vulnerable code is located in `util/webhook/webhook.go` around line 147, specifically when parsing the revision information. The issue is triggered when the `refUpdates` array is empty, causing a panic during slice access. **Recommendations** For versions 2.9.0-rc1 through 2.14.19, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. For versions 2.9.0-rc1 through 2.14.19, if Azure DevOps is not used, set the `webhook.azuredevops.username` and `webhook.azuredevops.password` to long, random values to effectively disable webhook handling for Azure DevOps payloads. For versions 3.0.0-rc1 through 3.2.0-rc1, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. For versions 3.0.0-rc1 through 3.2.0-rc1, if Azure DevOps is not used, set the `webhook.azuredevops.username` and `webhook.azuredevops.password` to long, random values to effectively disable webhook handling for Azure DevOps payloads. For version 3.1.6, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. For version 3.1.6, if Azure DevOps is not used, set the `webhook.azuredevops.username` and `webhook.azuredevops.password` to long, random values to effectively disable webhook handling for Azure DevOps payloads. For version 3.0.17, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. For version 3.0.17, if Azure DevOps is not used, set the `webhook.azuredevops.username` and `webhook.azuredevops.password` to long, random values to effectively disable webhook handling for Azure DevOps payloads.

**Name of the Vulnerable Software and Affected Versions** Argo CD versions 1.2.0 through 1.8.7 Argo CD versions 2.0.0-rc1 through 2.14.19 Argo CD versions 3.0.0-rc1 through 3.2.0-rc1 Argo CD version 3.1.7 Argo CD version 3.0.18 **Description** Argo CD is susceptible to malicious API requests that can lead to a denial of service, crashing the API server and disrupting service for legitimate users. Specifically, the `/api/webhook` endpoint is vulnerable when the `webhook.gogs.secret` is not configured. In this scenario, receiving a Gogs push event with a missing or null `commits[].repo` JSON field causes the `argocd-server` process to crash. The `affectedRevisionInfo` function lacks proper data structure validation for webhook event types, allowing an attacker to exploit this by sending crafted data. The vulnerability resides in the `Handler` function, which parses webhook type messages based on the `header` and `body` parameters. The `Parse` function unmarshals JSON-type messages without strict validation. An attacker can repeatedly send unauthenticated requests to the `/api/webhook` endpoint to cause a denial of service. **Recommendations** For versions 1.2.0 through 1.8.7, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. For versions 2.0.0-rc1 through 2.14.19, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. For versions 3.0.0-rc1 through 3.2.0-rc1, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. For version 3.1.7, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. For version 3.0.18, configure a webhook secret to ensure only trusted parties can invoke the webhook handler. If Gogs is not used, set the `webhook.gogs.secret` to a long, random value to disable Gogs payload handling.

Name of the Vulnerable Software and Affected Versions: Helm versions prior to 3.18.5 Description: Helm is a package manager for Charts for Kubernetes. An improper validation of type error when parsing `Chart.yaml` and `index.yaml` files can lead to a panic. This issue impacts YAML validation where a `Chart.yaml` file has a `null` maintainer or the `child` or `parent` of a dependencies `import-values` can be parsed as something other than a string, causing `helm lint` to panic. Additionally, an empty entry in the list of chart versions within an `index.yaml` can cause Helm to panic. Recommendations: Update to Helm version 3.18.5 or later. Ensure YAML files are formatted as Helm expects prior to processing them with Helm.

Name of the Vulnerable Software and Affected Versions: Helm versions prior to 3.18.5 Description: Helm, a package manager for Kubernetes Charts, is susceptible to a denial-of-service issue. A crafted JSON Schema file can cause Helm to exhaust available memory, leading to an out-of-memory (OOM) termination. This occurs when the `$ref` field in ` values.schema.json ` points to a device or problematic file, such as `/dev/zero`. Recommendations: Helm versions prior to 3.18.5 should be updated to version 3.18.5 or later. Ensure all Helm charts loaded into Helm do not have any reference of `$ref` pointing to `/dev/zero`.

Name of the Vulnerable Software and Affected Versions: Helm versions prior to 3.18.4 Description: A specially crafted `Chart.yaml` file along with a specially linked `Chart.lock` file can lead to local code execution when dependencies are updated. Fields in a `Chart.yaml` file can be crafted to cause execution if the content were in a file that is executed, such as a `bash.rc` file or shell script. If the `Chart.lock` file is symlinked to one of these files, updating dependencies will write the lock file content to the symlinked file, leading to unwanted execution. This issue affects when dependencies are updated, for example, when `helm dependency update` is run. Recommendations: For Helm versions prior to 3.18.4, ensure the `Chart.lock` file in a chart is not a symlink prior to updating dependencies. Update to Helm v3.18.4 to resolve the issue.

Name of the Vulnerable Software and Affected Versions: Helm versions prior to 3.17.3 Description: A JSON Schema file within a chart can be crafted with a deeply nested chain of references, leading to parser recursion that can exceed the stack size limit and trigger a stack overflow. This issue was discovered by a Helm contributor. Recommendations: For versions prior to 3.17.3, update to Helm v3.17.3 to resolve the issue. As a temporary workaround, ensure that the JSON Schema within any charts loaded by Helm does not have a large number of nested references, specifically avoiding files larger than 10 MiB.

Name of the Vulnerable Software and Affected Versions: Helm versions prior to 3.17.3 Description: A specially crafted chart archive file can cause Helm to exhaust its memory, leading to an out-of-memory termination. This occurs when the file expands to be significantly larger uncompressed than compressed, with a difference of over 800 times. The issue is related to how Helm loads chart archive files. Recommendations: For versions prior to 3.17.3, update to Helm v3.17.3 to resolve the issue. As a temporary workaround, ensure that any chart archive files being loaded by Helm do not contain files that are large enough to cause the Helm Client or SDK to use up available memory leading to a termination.

Name of the Vulnerable Software and Affected Versions: Argo CD versions prior to 2.11.6 Argo CD versions prior to 2.10.15 Argo CD versions prior to 2.9.20 Description: The issue is related to an unauthenticated attacker sending a specially crafted large JSON payload to the "/api/webhook" endpoint, causing excessive memory allocation that leads to service disruption by triggering an Out Of Memory (OOM) kill. This poses a high risk to the availability of Argo CD deployments. The vulnerability can be exploited by sending a large, malicious request with headers, such as "X-GitHub-Event: push", that will make ArgoCD start allocating memory to parse the incoming request. Recommendations: For versions prior to 2.11.6, update to version 2.11.6 or later. For versions prior to 2.10.15, update to version 2.10.15 or later. For versions prior to 2.9.20, update to version 2.9.20 or later. As a temporary workaround, consider restricting access to the "/api/webhook" endpoint to minimize the risk of exploitation. Enforce a limit on the size of the request being parsed to prevent excessive memory allocation.

**Name of the Vulnerable Software and Affected Versions** Helm versions prior to 3.14.2 **Description** The issue is related to an uninitialized variable vulnerability when Helm parses index and plugin yaml files missing expected content. This can cause a panic in Helm when either an `index.yaml` file or a plugin's `plugin.yaml` file is missing all metadata. The vulnerability is found in the Helm SDK when using the `LoadIndexFile` or `DownloadIndexFile` functions in the `repo` package or the `LoadDir` function in the `plugin` package. For the Helm client, this impacts functions around adding a repository and all Helm functions if a malicious plugin is added. **Recommendations** If using Helm versions prior to 3.14.2, update to Helm v3.14.2 to resolve the issue. If a malicious plugin has been added and is causing all Helm client commands to panic, manually remove the malicious plugin from the filesystem. For Helm SDK versions prior to 3.14.2, calls to affected functions can use `recover` to catch the panic.