J311Yl0V3U

**Nome do Software Vulnerável e Versões Afetadas** Apache DolphinScheduler versões anteriores a 3.4.2 **Description** Uma falha de verificação de autorização na API DataSource permite que usuários não autenticados exponham metadados arbitrários de fontes de dados. Isso ocorre porque a API não exige login para acessar informações sensíveis de metadados. **Recommendations** Atualizar para a versão 3.4.2.

Incorrect Authorization vulnerability of `/v2` experimental interface in Apache DolphinScheduler. This issue affects Apache DolphinScheduler: before 3.4.2. Users are recommended to upgrade to version 3.4.2, which fixes the issue.

**Nome do Software Vulnerável e Versões Afetadas** Apache Camel K versões 2.0.0 a 2.8.0 Apache Camel K versões 2.9.0 a 2.9.1 Apache Camel K versão 2.10.0 **Descrição** Usuários autorizados em um namespace do Kubernetes podem criar um recurso de Build para controlar a geração de Pods em um namespace de sua escolha, incluindo o namespace do operador. Essa falha de cross-namespace permite que usuários sequestrem pods em namespaces seguros por meio de uma referência externamente controlada a um recurso em outra esfera e bypass de autorização via chave controlada pelo usuário. **Recomendações** Atualizar as versões 2.0.0 a 2.8.0 para 2.8.1. Atualizar as versões 2.9.0 a 2.9.1 para 2.9.2. Atualizar a versão 2.10.0 para 2.10.1.

**Nome do Software Vulnerável e Versões Afetadas** local-path-provisioner versões anteriores a 0.0.36 **Description** Um usuário malicioso com permissões para editar o ConfigMap `local-path-config` no namespace `local-path-storage` pode manipular o template `helperPod.yaml`. Este template é usado para criar HelperPods durante as operações de provisionamento e limpeza de PVC, mas não é suficientemente validado antes do uso. Um invasor pode injetar campos sensíveis de segurança, como `securityContext.privileged`, volumes `hostPath` e capacidades do Linux no template. Quando uma operação de PVC dispara a criação de um HelperPod, o provisionador utiliza o template controlado pelo invasor, resultando potencialmente em um pod privilegiado executando no nó de destino com o sistema de arquivos raiz do host montado. Isso permite que o invasor acesse arquivos confidenciais do host, leia tokens de ServiceAccount de outros pods no mesmo nó, acesse dados de volume de local-path de outros locatários ou modifique arquivos no nó host. **Recommendations** Atualize para a versão 0.0.36 ou posterior. Restrinja o acesso de escrita ao ConfigMap `local-path-config` no namespace `local-path-storage` apenas a administradores confiáveis. Marque o ConfigMap `local-path-config` como imutável. Habilite o Kubernetes Pod Security Admission para o namespace `local-path-storage`, aplicando a política `baseline` para evitar a criação de HelperPods privilegiados.

**Name of the Vulnerable Software and Affected Versions** Kube-router versions prior to 2.8.0 **Description** Kube-router's proxy module does not validate externalIPs or loadBalancer IPs before programming them into the node's network configuration. This impacts multi-tenant clusters where untrusted users have namespace-scoped permissions to create or modify Services. The `buildServicesInfo()` function copies IPs from `Service.spec.externalIPs` and `status.loadBalancer.ingress` without validating them against the `--service-external-ip-range` parameter. An attacker can bind arbitrary VIPs on all cluster nodes or cause denial of service to critical cluster services such as kube-dns. The `--service-external-ip-range` parameter is only used by the netpol module and is not checked by the proxy module. This allows attackers to potentially hijack traffic or disrupt DNS services. The vulnerability can be exploited by creating a Service with an externalIP matching the kube-dns ClusterIP, redirecting all DNS queries to attacker-controlled pods. The issue is not unique to kube-router, as the upstream Kubernetes project identified a similar issue as CVE-2020-8554. **Recommendations** Update to Kube-router version 2.8.0 or later.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Nuclio anteriores à 1.15.20 **Descrição** O componente Shell Runtime do Nuclio contém um problema de injeção de comando. Quando uma função é invocada via HTTP, o runtime lê o cabeçalho `X-Nuclio-Arguments` e incorpora diretamente seu valor em comandos de shell sem validação ou sanitização. Isso permite que invasores com permissões de invocação de função injetem comandos maliciosos, potencialmente executando código arbitrário com privilégios de root em contêineres de função, roubando Tokens de ServiceAccount com permissões de nível cluster-admin e, finalmente, obtendo controle completo sobre o cluster Kubernetes. A vulnerabilidade decorre da falta de validação ao processar argumentos fornecidos pelo usuário na função `getCommandArguments` e da subsequente execução desses argumentos usando `sh -c`. Os invasores podem explorar isso criando payloads maliciosos no cabeçalho `X-Nuclio-Arguments`, aproveitando metacaracteres de shell como ponto e vírgula, pipes e crases para injetar comandos arbitrários. A vulnerabilidade afeta todas as versões que incluem o componente Shell Runtime. Uma exploração bem-sucedida pode levar ao comprometimento completo do cluster, incluindo violações de dados, ataques à cadeia de suprimentos e implantação de ransomware. **Recomendações** Desative o Shell Runtime definindo `enabled: false` na configuração da plataforma Nuclio. Restrinja as permissões de implantação de funções usando Controle de Acesso Baseado em Função (RBAC) para limitar quem pode implantar funções. Implemente validação rigorosa de entrada na função `getCommandArguments` para filtrar caracteres inseguros. Remova o uso da execução `sh -c` e utilize execução de comando parametrizada em vez disso. Limite as permissões da ServiceAccount usada pelos pods de função para reduzir o impacto potencial de uma exploração bem-sucedida.