CVE-2026-59341 in sealed-secrets
Sumário
de VulDB • 15/09/2026
Existe uma vulnerabilidade de segurança nos endpoints POST não autenticados do controlador Sealed Secrets. Ao enviar um payload modificado contendo lógica personalizada de templates Go em spec.template.data, um atacante com acesso à rede interna pode abusar do manipulador como oráculo de descriptografia para recuperar o texto claro completo de qualquer segredo selado.
Os handlers POST /v1/verify e /v1/rotate chamam Unseal() para descriptografar os alvos secretos, em seguida, renderizam quaisquer templates Go encontrados em spec.template.data.* usando o payload descriptografado como contexto de avaliação (pkg/apis/sealedsecrets/v1alpha1/sealedsecret_expansion.go). Os erros encontrados durante a execução do template são refletidos diretamente nos códigos de status da resposta HTTP resultante.
Falta vinculação de rótulo AEAD: o campo spec.template.data é omitido da vinculação de dados autenticados (authenticated-data) do AEAD ao criptograma em relação aos metadados. Como resultado, um atacante pode copiar os metadados válidos e encryptedData de um alvo literalmente, satisfazendo a descriptografia AEAD e a validação de rótulo, enquanto substitui livremente spec.template.data por lógica de template arbitrária.
Oráculo de canal lateral: erros na execução do mapeamento diretamente para códigos de resposta HTTP. HTTP 200 (OK) indica que a execução do template foi bem-sucedida; HTTP 409 (Conflict/Conflito) indica falha na execução do template (por exemplo, via {{ fail "..." }}).
Ao injetar instruções condicionais como {{ if eq (substr 0 1 .password) "S" }}ok{{ else }}{{ fail "x" }}{{ end }}, um atacante recebe status HTTP 200 quando o palpite de caractere está correto e HTTP 409 quando está incorreto. Essa resposta diferencial vaza um bit de igualdade por caractere a cada solicitação, permitindo a extração completa do segredo através de consultas sucessivas.
Vetor de ataque e pré-requisitos: não autenticado; requer acesso à rede à porta interna do serviço do controlador (:8080). Embora este serviço não esteja exposto à internet pública por padrão, ele é acessível a qualquer pod dentro do cluster Kubernetes ou via uma conexão kubectl port-forward.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.