Uma das falhas permite herdar montagens de containers pelo Docker Compose e pode expor o socket Docker. As outras atingem a execução de comandos no Kubernetes e as permissões de compartilhamento entre equipes. Você precisa conferir o tipo de ambiente administrado e os acessos concedidos, além da versão instalada.
Aplicativo
Portainer
Data do compilado
Vulnerabilidades
3
Os três avisos abrangem as edições Community e Business. As pontuações são do CVSS 4.0. A indicação de correção disponível descreve as versões do projeto e não confirma a atualização da sua instância.
Gravidade críticaCVSS: 9,4/10Correção disponível
Stacks podem herdar montagens do host apesar da restrição a bind mounts
A opção Hide bind mounts for non-administrators deveria recusar montagens do host nas stacks criadas por usuários sem privilégios administrativos. O validador conferia os campos volumes, mas ignorava volumes_from, que permite ao serviço herdar as montagens de outro container. Em um ambiente Docker standalone, um usuário padrão com acesso à gestão de stacks pode aproveitar essa omissão para alcançar arquivos do host. Quando a montagem herdada contém o socket Docker, o acesso permite controlar o daemon e comprometer os containers daquele servidor.
Casos de uso afetados
Você permite que usuários padrão implantem stacks em um ambiente Docker standalone e mantém a restrição a bind mounts habilitada. Um container existente com o socket Docker montado pode fornecer esse acesso por herança.
Um container referenciado pela stack monta o diretório de armazenamento do Portainer Server. A herança dessa montagem pode expor o banco do Portainer, incluindo credenciais armazenadas e material de assinatura.
Confira na sua instância
Confira a versão do Portainer e a opção Hide bind mounts for non-administrators em cada ambiente Docker standalone. Examine os arquivos Compose das stacks pertencentes a usuários não administradores e procure volumes_from. Para cada ocorrência, identifique o container referenciado e confira suas montagens, especialmente o socket Docker e o diretório de armazenamento do Portainer. Após atualizar para 2.45.3, valide em um ambiente de teste que uma stack com volumes_from seja recusada para um usuário padrão quando a restrição estiver habilitada. Use containers de teste sem arquivos sensíveis nessa conferência.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.39.x
>= 2.39.0, <= 2.39.8
Não informadas
2.40.x a 2.45.x
>= 2.40.0, <= 2.45.2
2.45.3
A API deixa patched_versions vazio para a linha 2.39.x. O aviso informa que essa linha não receberá uma versão de correção e orienta a atualização para 2.45.3. As stacks Swarm não são afetadas por esse caminho. Enquanto você prepara a atualização, a opção Hide the use of Stacks for non-administrators recusa a criação e a gestão de stacks por usuários não administradores, retirando também esse uso legítimo.
Gravidade moderadaCVSS: 6,5/10Correção disponível
Shell Kubernetes pode executar comandos em outro Pod com os privilégios do Agent
Ao abrir o shell kubectl pelo navegador, o Portainer cria um Pod temporário para a sessão. O servidor acrescentava o destino e o comando à URL recebida, preservando valores enviados pelo cliente. Como o Agent utilizava a primeira ocorrência de cada parâmetro, um usuário autenticado com o papel padrão podia desviar a execução para outro Pod. A execução usa a identidade de serviço do Agent, associada a cluster-admin no manifesto oficial, permitindo alcançar qualquer namespace e os Secrets do cluster.
Casos de uso afetados
Você administra um cluster Kubernetes pelo Agent ou Edge Agent e concede acesso comum ao ambiente. Um usuário padrão pode alcançar Pods fora do namespace ao qual deveria ter acesso.
Você restringe as credenciais pessoais pelo controle de acesso do Kubernetes, mas mantém o Agent com cluster-admin. Essas restrições pessoais não limitam a execução desviada, pois ela utiliza a identidade do Agent.
Confira na sua instância
Identifique quais ambientes Kubernetes usam Agent ou Edge Agent e compare a versão instalada com as correções 2.39.6 e 2.45.0 nas linhas correspondentes. Confira a associação de permissões da identidade de serviço do Agent. Nos logs de auditoria do Kubernetes, examine as chamadas pods/exec feitas por essa identidade e compare o Pod de destino com as sessões legítimas de shell. Investigue execuções em Pods que não correspondam a essas sessões e substitua os Secrets potencialmente expostos quando houver indicação de uso indevido.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.39.x
>= 2.39.0, < 2.39.6
2.39.6
2.40.x a 2.44.x
>= 2.40.0, < 2.45.0
2.45.0
A conexão Kubernetes local não é afetada por esse caminho. Na Business Edition, você pode desativar o shell Kubernetes para não administradores durante a preparação da atualização. A Community Edition não oferece essa opção e exige restringir os ambientes afetados a administradores como medida temporária. A correção substitui os parâmetros enviados pelo cliente, mas mantém a execução sob a identidade do Agent.
Gravidade moderadaCVSS: 5,3/10Correção disponível
Compartilhamento de recursos aceita equipes sem vínculo com o usuário
Um usuário não administrador que já controla um recurso pode conceder acesso a equipes das quais não participa. A função AuthorizedResourceControlUpdate encerrava a validação ao encontrar uma equipe permitida ou o acesso individual do próprio usuário, deixando outras equipes sem conferência. O processamento também aplicava as listas recebidas ao recurso antes de verificar a autorização. Assim, uma stack ou um Secret que deveria permanecer restrito pode ficar disponível para outras equipes, com as permissões de gestão correspondentes.
Casos de uso afetados
Você separa as stacks por equipes no Portainer. Um integrante que já controla uma stack pode compartilhá-la com outra equipe sem fazer parte dela, permitindo que seus membros gerenciem aquele recurso.
Você concede a um usuário a propriedade de um Secret ou de uma configuração. A falha permite ampliar o compartilhamento para equipes não autorizadas pela política de acesso da instância.
Confira na sua instância
Abra os controles de acesso das stacks, dos Secrets e das configurações sensíveis. Compare as equipes autorizadas em cada recurso com os vínculos dos usuários que podem alterar seu compartilhamento. Examine também registros de requisições PUT /api/resource_controls/{id} que acrescentem várias equipes. Após atualizar para uma versão com a correção completa, confira em um recurso de teste que um usuário não administrador não consiga incluir uma equipe da qual não participa nem combinar acesso individual com acessos de equipes.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.39.x
>= 2.39.0, < 2.40.0
Não informadas
2.40.x a 2.45.x
>= 2.40.0, < 2.45.2
2.45.2
As versões 2.39.3 e 2.43.0 corrigiram apenas um dos caminhos. A correção completa está em 2.45.2. A API mantém patched_versions vazio para 2.39.x, cujo ajuste ainda aguardava lançamento no aviso consultado. A falha exige controle prévio sobre o recurso e não concede, por si só, acesso a recursos de outros proprietários ou ao host.
Programador há mais de 20 anos, fundador da Powertic e da Promovaweb. Embaixador do n8n no Brasil e da Baserow, Chatwoot, Miro e Kestra. Membro do Product Team do Mautic.
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
