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.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Argo CD de 1.2.0 a 1.8.7 Versões do Argo CD de 2.0.0-rc1 a 2.14.19 Versões do Argo CD de 3.0.0-rc1 a 3.2.0-rc1 Versão 3.1.7 do Argo CD Versão 3.0.18 do Argo CD **Descrição** O Argo CD está suscetível a negação de serviço através de requisições de API maliciosas. Especificamente, quando um `webhook.bitbucketserver.secret` não está configurado, o endpoint `/api/webhook` falha ao receber um payload malformado do Bitbucket Server onde o campo `repository.links.clone` não é um array. Uma única requisição não autenticada pode fazer com que o servidor da API entre em um estado CrashLoopBackOff, e atingir todas as réplicas pode resultar em uma indisponibilidade completa da API. O problema origina-se de uma assertiva de tipo insegura dentro do arquivo `webhook.go`, que entra em panic quando o tipo de array esperado não é atendido. Uma prova de conceito (PoC) demonstra que enviar um payload JSON manipulado para o endpoint `/api/webhook` pode acionar esse panic e derrubar o servidor. **Recomendações** Para as versões do Argo CD de 1.2.0 a 1.8.7, configure um `webhook.bitbucketserver.secret` para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para as versões do Argo CD de 2.0.0-rc1 a 2.14.19, configure um `webhook.bitbucketserver.secret` para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para as versões do Argo CD de 3.0.0-rc1 a 3.2.0-rc1, configure um `webhook.bitbucketserver.secret` para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para a versão 3.1.7 do Argo CD, configure um `webhook.bitbucketserver.secret` para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para a versão 3.0.18 do Argo CD, configure um `webhook.bitbucketserver.secret` para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Se o Bitbucket Server não for utilizado, defina o `webhook.bitbucketserver.secret` para um valor longo e aleatório para efetivamente desabilitar o tratamento de webhook para payloads do Bitbucket Server.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Argo CD 2.9.0-rc1 até 2.14.19 Versões do Argo CD 3.0.0-rc1 até 3.2.0-rc1 Versão do Argo CD 3.1.6 Versão do Argo CD 3.0.17 **Descrição** O Argo CD, uma ferramenta de entrega contínua GitOps declarativa para Kubernetes, está suscetível a um problema de negação de serviço. Quando o `webhook.azuredevops.username` e o `webhook.azuredevops.password` não estão definidos na configuração padrão, o endpoint `/api/webhook` faz falhar todo o processo `argocd-server` ao receber um evento Push do Azure DevOps com um array JSON `resource.refUpdates` vazio. Isso ocorre porque o código tenta acessar o primeiro elemento (`[0]`) do slice `resource.refUpdates` sem verificar seu comprimento, levando a um panic de índice fora do intervalo. Uma única requisição HTTP POST não autenticada para o endpoint `/api/webhook` é suficiente para encerrar o processo. O código vulnerável está localizado em `util/webhook/webhook.go` por volta da linha 147, especificamente ao analisar as informações de revisão. O problema é acionado quando o array `refUpdates` está vazio, causando um panic durante o acesso ao slice. **Recomendações** Para as versões 2.9.0-rc1 até 2.14.19, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para as versões 2.9.0-rc1 até 2.14.19, se o Azure DevOps não for utilizado, defina o `webhook.azuredevops.username` e o `webhook.azuredevops.password` para valores longos e aleatórios para efetivamente desabilitar a manipulação de webhook para payloads do Azure DevOps. Para as versões 3.0.0-rc1 até 3.2.0-rc1, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para as versões 3.0.0-rc1 até 3.2.0-rc1, se o Azure DevOps não for utilizado, defina o `webhook.azuredevops.username` e o `webhook.azuredevops.password` para valores longos e aleatórios para efetivamente desabilitar a manipulação de webhook para payloads do Azure DevOps. Para a versão 3.1.6, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para a versão 3.1.6, se o Azure DevOps não for utilizado, defina o `webhook.azuredevops.username` e o `webhook.azuredevops.password` para valores longos e aleatórios para efetivamente desabilitar a manipulação de webhook para payloads do Azure DevOps. Para a versão 3.0.17, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para a versão 3.0.17, se o Azure DevOps não for utilizado, defina o `webhook.azuredevops.username` e o `webhook.azuredevops.password` para valores longos e aleatórios para efetivamente desabilitar a manipulação de webhook para payloads do Azure DevOps.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Argo CD 1.2.0 a 1.8.7 Versões do Argo CD 2.0.0-rc1 a 2.14.19 Versões do Argo CD 3.0.0-rc1 a 3.2.0-rc1 Versão do Argo CD 3.1.7 Versão do Argo CD 3.0.18 **Descrição** O Argo CD está suscetível a requisições de API maliciosas que podem levar a uma negação de serviço, causando a falha do servidor de API e interrompendo o serviço para usuários legítimos. Especificamente, o endpoint `/api/webhook` é vulnerável quando o `webhook.gogs.secret` não está configurado. Neste cenário, receber um evento de push do Gogs com um campo JSON `commits[].repo` ausente ou nulo causa a falha do processo `argocd-server`. A função `affectedRevisionInfo` carece de validação adequada da estrutura de dados para tipos de eventos de webhook, permitindo que um atacante explore isso enviando dados manipulados. A vulnerabilidade reside na função `Handler`, que analisa mensagens do tipo webhook com base nos parâmetros `header` e `body`. A função `Parse` desserializa mensagens do tipo JSON sem validação estrita. Um atacante pode enviar repetidamente requisições não autenticadas para o endpoint `/api/webhook` para causar uma negação de serviço. **Recomendações** Para as versões 1.2.0 a 1.8.7, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para as versões 2.0.0-rc1 a 2.14.19, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para as versões 3.0.0-rc1 a 3.2.0-rc1, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para a versão 3.1.7, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Para a versão 3.0.18, configure um segredo de webhook para garantir que apenas partes confiáveis possam invocar o manipulador de webhook. Se o Gogs não for utilizado, defina o `webhook.gogs.secret` para um valor longo e aleatório para desabilitar o processamento de payload do Gogs.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores à 3.18.5 Descrição: O Helm é um gerenciador de pacotes para Charts do Kubernetes. Uma validação inadequada de tipo ao analisar os arquivos `Chart.yaml` e `index.yaml` pode levar a um panic. Este problema impacta a validação YAML onde um arquivo `Chart.yaml` possui um mantenedor `null` ou onde o `child` ou `parent` de um `import-values` de dependências pode ser analisado como algo diferente de uma string, causando um panic no `helm lint`. Além disso, uma entrada vazia na lista de versões do chart dentro de um `index.yaml` pode causar um panic no Helm. Recomendações: Atualize para a versão 3.18.5 ou posterior do Helm. Garanta que os arquivos YAML estejam formatados como o Helm espera antes de processá-los com o Helm.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores à 3.18.5 Descrição: O Helm, um gerenciador de pacotes para Charts do Kubernetes, está suscetível a uma vulnerabilidade de negação de serviço. Um arquivo JSON Schema manipulado pode fazer com que o Helm esgote a memória disponível, levando a um encerramento por falta de memória (OOM). Isso ocorre quando o campo `$ref` em ` values.schema.json ` aponta para um dispositivo ou arquivo problemático, como `/dev/zero`. Recomendações: As versões do Helm anteriores à 3.18.5 devem ser atualizadas para a versão 3.18.5 ou posterior. Garanta que todos os Charts do Helm carregados no Helm não possuam nenhuma referência `$ref` apontando para `/dev/zero`.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores à 3.18.4 Descrição: Um arquivo `Chart.yaml` especialmente criado, juntamente com um arquivo `Chart.lock` vinculado especificamente, pode levar à execução local de código quando as dependências são atualizadas. Campos em um arquivo `Chart.yaml` podem ser manipulados para causar execução caso o conteúdo esteja em um arquivo que é executado, como um arquivo `bash.rc` ou script shell. Se o arquivo `Chart.lock` for um link simbólico para um desses arquivos, a atualização das dependências escreverá o conteúdo do arquivo lock no arquivo vinculado, levando à execução indesejada. Este problema ocorre quando as dependências são atualizadas, por exemplo, ao executar `helm dependency update`. Recomendações: Para versões do Helm anteriores à 3.18.4, certifique-se de que o arquivo `Chart.lock` em um chart não seja um link simbólico antes de atualizar as dependências. Atualize para o Helm v3.18.4 para resolver o problema.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores à 3.17.3 Descrição: Um arquivo JSON Schema dentro de um chart pode ser criado com uma cadeia de referências profundamente aninhada, levando à recursão do parser que pode exceder o limite de tamanho da pilha e causar um estouro de pilha. Este problema foi descoberto por um contribuidor do Helm. Recomendações: Para versões anteriores à 3.17.3, atualize para o Helm v3.17.3 para resolver o problema. Como solução alternativa temporária, certifique-se de que o JSON Schema dentro de quaisquer charts carregados pelo Helm não possua um grande número de referências aninhadas, evitando especificamente arquivos maiores que 10 MiB.

Nome do Software Vulnerável e Versões Afetadas: Versões do Helm anteriores a 3.17.3 Descrição: Um arquivo de chart especialmente construído pode fazer com que o Helm esgote sua memória, levando a uma terminação por falta de memória. Isso ocorre quando o arquivo se expande para um tamanho significativamente maior quando descompactado em comparação ao compactado, com uma diferença de mais de 800 vezes. O problema está relacionado à maneira como o Helm carrega arquivos de chart. Recomendações: Para versões anteriores a 3.17.3, atualize para o Helm v3.17.3 para resolver o problema. Como medida temporária de contorno, garanta que quaisquer arquivos de chart carregados pelo Helm não contenham arquivos grandes o suficiente para fazer com que o Cliente ou SDK do Helm esgote a memória disponível, levando a uma terminação.

Nome do software vulnerável e versões afetadas: Versões do Argo CD anteriores à 2.11.6 Versões do Argo CD anteriores à 2.10.15 Versões do Argo CD anteriores à 2.9.20 Descrição: O problema está relacionado a um invasor não autenticado que envia uma carga JSON grande e especialmente criada para o endpoint “/api/webhook”, causando alocação excessiva de memória que leva à interrupção do serviço ao acionar um kill por falta de memória (OOM). Isso representa um alto risco para a disponibilidade das implantações do Argo CD. A vulnerabilidade pode ser explorada enviando-se uma solicitação maliciosa de grande porte com cabeçalhos, como “X-GitHub-Event: push”, que fará com que o ArgoCD comece a alocar memória para analisar a solicitação recebida. Recomendações: Para versões anteriores à 2.11.6, atualize para a versão 2.11.6 ou posterior. Para versões anteriores à 2.10.15, atualize para a versão 2.10.15 ou posterior. Para versões anteriores à 2.9.20, atualize para a versão 2.9.20 ou posterior. Como solução alternativa temporária, considere restringir o acesso ao endpoint “/api/webhook” para minimizar o risco de exploração. Aplique um limite ao tamanho da solicitação que está sendo analisada para evitar alocação excessiva de memória.

**Nome do software vulnerável e versões afetadas** Versões do Helm anteriores à 3.14.2 **Descrição** O problema está relacionado a uma vulnerabilidade de variável não inicializada quando o Helm analisa arquivos YAML de índice e de plug-ins que não contêm o conteúdo esperado. Isso pode causar um erro grave no Helm quando um arquivo `index.yaml` ou o arquivo `plugin.yaml` de um plug-in não contém nenhum metadado. A vulnerabilidade é encontrada no Helm SDK ao usar as funções `LoadIndexFile` ou `DownloadIndexFile` no pacote `repo` ou a função `LoadDir` no pacote `plugin`. Para o cliente Helm, isso afeta funções relacionadas à adição de um repositório e todas as funções do Helm caso um plugin malicioso seja adicionado. **Recomendações** Se estiver usando versões do Helm anteriores à 3.14.2, atualize para o Helm v3.14.2 para resolver o problema. Se um plugin malicioso tiver sido adicionado e estiver causando pânico em todos os comandos do cliente Helm, remova manualmente o plugin malicioso do sistema de arquivos. Para versões do Helm SDK anteriores à 3.14.2, as chamadas às funções afetadas podem usar `recover` para interceptar o pânico.