Os seis avisos incluem duas falhas críticas que permitem acesso ao host Docker por usuários sem perfil de administrador. Há também exclusão indevida de registros de namespaces, acesso ao Kubernetes após revogação, exposição de vínculos entre usuários e equipes e requisições indevidas pela rede do servidor. Para conferir sua instalação, compare a versão em execução com cada faixa e revise as permissões e os recursos descritos nas fichas.
AplicativoPortainer
Data do compilado
Vulnerabilidades6
As pontuações são do CVSS 4.0 informado nos avisos. O estado de correção indica uma versão disponibilizada pelo projeto, sem confirmar a atualização da sua instalação. As faixas e os campos de versões corrigidas preservam os valores da API, inclusive strings vazias quando não há versão indicada naquela entrada.
Gravidade críticaCVSS: 9,4/10Correção disponível
Arquivos do host expostos por configs e secrets do Compose
A restrição de bind mounts verificava os volumes do Compose, mas deixava de examinar os caminhos de arquivos declarados em configs e secrets. Um usuário padrão com acesso ao ambiente Docker e permissão para gerenciar stacks podia usar esses campos para montar arquivos externos ao diretório da stack. Isso permite ler arquivos do host e, quando a montagem alcança o socket Docker, controlar o daemon. No Swarm, campos como env_file também podem provocar a leitura de arquivos pelo próprio servidor Portainer.
Casos de uso afetados
Você permite que usuários padrão implantem stacks e mantém Hide bind mounts for non-administrators ativado. A restrição continua sujeita ao desvio pelos campos de arquivos do Compose nas versões afetadas.
Você administra stacks Swarm com arquivos referenciados por env_file ou por configs e secrets. Caminhos externos ao diretório da stack podem expor arquivos acessíveis ao processo do Portainer.
Confira na sua instância
Confira a versão do servidor e abra os arquivos Compose das stacks mantidas por usuários sem perfil de administrador. Examine as referências file de configs e secrets, além de env_file, procurando caminhos absolutos ou sequências ../ que saiam do diretório da stack. Verifique também as montagens dos containers já implantados, especialmente qualquer referência ao socket Docker. Até atualizar, a opção Hide the use of Stacks for non-administrators restringe a criação e o gerenciamento de stacks por usuários padrão.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/portainer/portainer — 2.39.x
>= 2.39.0, <= 2.39.8
Não informadas
github.com/portainer/portainer — 2.40.x a 2.45.x
>= 2.40.0, <= 2.45.1
2.45.2
O aviso abrange Community Edition e Business Edition. A linha 2.39.x não recebeu uma versão de correção para esta falha, por isso o comunicado orienta migrar para 2.45.2. A restrição de stacks é uma medida temporária e ainda permite implantações por administradores do ambiente.
Gravidade críticaCVSS: 9,4/10Correção disponível
Volumes locais e redeploy automático contornam restrições de montagem
Os filtros de montagem reconheciam formas literais de bind mount, mas não examinavam corretamente as opções do driver local nem normalizavam maiúsculas e minúsculas. Um usuário padrão com permissão para criar containers, volumes ou serviços podia montar caminhos do host apesar da restrição configurada. Havia também uma falha no redeploy automático de stacks Git: o Portainer implantava o Compose atualizado sem reaplicar as verificações de segurança do ambiente. Uma alteração no repositório podia, portanto, introduzir montagens do host ou execução privilegiada.
Casos de uso afetados
Você mantém Hide bind mounts for non-administrators ativado e permite a criação de recursos Docker por usuários padrão. Nas versões afetadas, as opções do driver local podem contornar essa restrição.
Uma stack de usuário sem perfil de administrador recebe atualizações por webhook ou consulta periódica ao Git. O arquivo aprovado na implantação inicial pode ser substituído no repositório e reaplicado automaticamente sem a validação correspondente.
Confira na sua instância
Inspecione os volumes do driver local e procure opções o com bind ou rbind, além de device apontando para caminhos do host. Nos containers e serviços Swarm, confira as opções DriverConfig das montagens. Para stacks Git, revise os webhooks, os intervalos de atualização e os commits aplicados automaticamente. Compare o Compose com as montagens e permissões efetivas dos containers, incluindo execução privilegiada e uso do PID do host. Até instalar a correção completa, desative as atualizações automáticas das stacks mantidas por usuários padrão.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/portainer/portainer — 2.40.x a 2.45.x
>= 2.40.0, < 2.45.2
2.45.2
github.com/portainer/portainer — entrada da API referente à linha 2.39.x
>= 2.39.0
Não informadas
As versões 2.39.7 e 2.45.0 corrigiram os caminhos pela API Docker e pela implantação interativa. O redeploy automático continuou afetado, inclusive em 2.39.8 e 2.45.1, e recebeu correção em 2.45.2. A API informa >= 2.39.0 sem limite superior na entrada associada à linha 2.39.x. Esse valor foi preservado, mas o texto do aviso informa a correção completa na 2.45.2.
Gravidade altaCVSS: 7,1/10Correção disponível
Exclusão recusada pelo Kubernetes apaga registros do namespace no Portainer
Ao receber uma solicitação de exclusão de namespace, o Portainer removia suas políticas de acesso, vínculos com registries e registros de stacks antes de encaminhar a operação ao Kubernetes. Quando o cluster negava a exclusão, esses registros não eram restaurados. Um usuário autenticado com acesso ao ambiente podia, assim, apagar informações de gerenciamento de namespaces de outros usuários, mesmo sem permissão para excluir esses namespaces no cluster.
Casos de uso afetados
Você compartilha um ambiente Kubernetes entre usuários com permissões diferentes por namespace. Um integrante com acesso ao ambiente pode afetar os registros de namespaces administrados por outros integrantes.
As aplicações continuam no cluster, mas uma stack desaparece do Portainer ou o acesso ao namespace deixa de funcionar. Essa divergência entre o cluster e o painel corresponde ao efeito descrito no aviso.
Confira na sua instância
Compare os namespaces e as aplicações existentes no Kubernetes com as stacks e políticas exibidas no Portainer. Quando houver desaparecimento inesperado de registros, procure solicitações de exclusão recusadas nos logs de auditoria do cluster e confira os vínculos do namespace com os registries. Verifique a disponibilidade de um backup recente do Portainer para recuperar os registros removidos. A conferência deve usar consultas de leitura, sem tentar excluir namespaces de produção.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/portainer/portainer — 2.39.x
>= 2.39.0, < 2.40.0
Não informadas
github.com/portainer/portainer — 2.40.x a 2.45.x
>= 2.40.0, < 2.45.2
2.45.2
A falha não exclui o namespace nem suas aplicações. A remoção das políticas pode retirar vínculos de autorização na sincronização seguinte. A versão 2.45.2 só remove os registros do Portainer depois que o Kubernetes aceita a exclusão.
Gravidade moderadaCVSS: 5,8/10Correção disponível
Shell do Kubernetes mantém acesso após revogação de permissões
O endpoint /websocket/kubernetes-shell não conferia a autorização para o ambiente selecionado. Ao mesmo tempo, a revogação de acesso podia deixar service accounts e seus vínculos de permissão no cluster. A presença dessas credenciais permitia abrir uma sessão kubectl mesmo após a retirada da autorização no Portainer. O alcance da sessão dependia das permissões da service account remanescente, podendo incluir leitura de Secrets e alteração ou exclusão de aplicações.
Casos de uso afetados
Você removeu o acesso de um usuário ou de uma equipe a um ambiente Kubernetes, mas as service accounts correspondentes ainda existem no namespace portainer com permissões utilizáveis.
Você atualizou somente para uma versão com a primeira etapa da correção. A conferência de acesso ao shell já existe, mas a limpeza das credenciais após revogações ainda precisa da segunda etapa.
Confira na sua instância
No namespace portainer de cada cluster gerenciado, compare as service accounts de usuários e equipes com as autorizações atuais do ambiente. Examine os RoleBindings e ClusterRoleBindings associados aos acessos revogados e remova os vínculos órfãos após confirmar sua origem. Consulte os logs de auditoria para identificar criação de pods de shell sem autorização correspondente. A versão instalada precisa conter tanto a validação do endpoint quanto a limpeza das permissões.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/portainer/portainer — 2.39.x
>= 2.39.0, < 2.39.6
2.39.6
github.com/portainer/portainer — 2.40.x a 2.44.x
>= 2.40.0, < 2.44.0
2.44.0
A exploração exige uma service account do usuário ou de sua equipe no cluster de destino. A Business Edition oferece Disable kube shell como medida temporária para usuários sem perfil de administrador. A Community Edition não possui essa opção. O aviso orienta migrar das linhas 2.40.x a 2.44.x para 2.45.2.
Gravidade moderadaCVSS: 5,3/10Correção disponível
Líder de equipe consegue consultar vínculos de outras equipes
A listagem GET /api/team_memberships verificava apenas se o usuário liderava alguma equipe e retornava todos os vínculos cadastrados na instalação. Com isso, um líder podia consultar TeamID, UserID e Role de equipes fora de sua administração. A combinação desses registros com a listagem de usuários permitia identificar integrantes e líderes de outros grupos. A falha expõe informações de associação, mas não concede permissão para alterar esses vínculos.
Casos de uso afetados
Você usa equipes distintas para separar o acesso de clientes ou áreas internas. Um líder de uma dessas equipes pode consultar associações pertencentes às demais nas versões afetadas.
Você delegou a gestão de integrantes a líderes sem perfil de administrador. Essa função é suficiente para alcançar a listagem vulnerável, mesmo sem participação nas outras equipes.
Confira na sua instância
Em uma instalação de teste, use um usuário que lidere somente uma equipe e consulte GET /api/team_memberships. Compare os TeamID retornados com as equipes que esse usuário administra. Após a correção, a resposta deve conter somente vínculos das equipes sob sua liderança. Revise também as atribuições de líder na instalação para retirar permissões de gestão que já não sejam necessárias.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/portainer/portainer — 2.39.x
>= 2.39.0, < 2.39.6
2.39.6
github.com/portainer/portainer — 2.40.x a 2.44.x
>= 2.40.0, < 2.44.0
2.44.0
A listagem vulnerável retorna identificadores e funções dos vínculos, sem nomes de equipes. O aviso não atribui a essa falha acesso direto aos ambientes Docker ou Kubernetes. As operações de alteração dos vínculos mantêm suas verificações de autorização.
Gravidade moderadaCVSS: 5,3/10Correção disponível
URLs de integrações permitem requisições indevidas pela rede do servidor
Recursos que consultam repositórios Git, charts Helm e registries aceitavam destinos fornecidos pelo usuário sem validar o endereço de rede resultante da resolução do nome. Outros caminhos afetados incluem manifests por URL, o proxy do GitLab e a consulta ao provedor OAuth. Um usuário autenticado com acesso a um desses recursos podia provocar requisições do servidor Portainer a serviços internos. Nos caminhos que devolvem o conteúdo da resposta, isso pode expor informações desses serviços ou credenciais de metadados da nuvem, conforme o acesso de rede disponível.
Casos de uso afetados
Você hospeda o Portainer em uma rede com serviços internos acessíveis pelo servidor e permite que usuários cadastrem repositórios ou consultem registries. As requisições podem alcançar destinos que esses usuários não acessariam diretamente.
O host do Portainer consegue acessar o serviço de metadados da nuvem. Um caminho que devolva a resposta pode expor credenciais disponíveis nesse serviço.
Você configurou a URI de recurso do OAuth. Essa consulta encaminha um token Bearer ao destino informado, portanto a revisão também precisa incluir essa configuração administrativa.
Confira na sua instância
Confira a versão e a edição do Portainer, depois examine os controles de saída de rede do host. O servidor deve alcançar somente os destinos necessários às integrações, com acesso ao endereço 169.254.169.254 e a redes internas desnecessárias recusado pela configuração de rede. Na Business Edition, confira se o modo SSRF permanece desativado, em Audit ou em Enforce. Use Audit para revisar os destinos legítimos e ajuste a lista permitida antes de aplicar Enforce. Examine os logs de saída para localizar conexões inesperadas.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/portainer/portainer — faixa consolidada da API
>= 2.39.0, < 2.45.1
2.45.1
A 2.45.1 completa a cobertura dos caminhos descritos, mas a atualização não ativa o modo SSRF. Esse controle está disponível somente na Business Edition e vem desativado. A Community Edition depende da segmentação e da filtragem de saída da rede. Caminhos sem retorno do corpo da resposta podem revelar serviços por erros e tempo de resposta, sem necessariamente permitir a leitura de credenciais.
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.
