Os oito avisos incluem falhas que permitem acessar arquivos reservados e executar código no host Docker a partir de acessos limitados no Portainer. Você pode conferir quais recursos utiliza e comparar a versão instalada com a faixa de cada ficha. As correções variam conforme a falha, inclusive dentro da linha 2.39.x.
AplicativoPortainer
Data do compilado
Vulnerabilidades8
A indicação de correção informa que o projeto publicou uma versão corrigida. Você precisa confirmar qual versão está em execução na sua instância para verificar se ela recebeu a atualização.
Gravidade críticaCVSS: 9,4/10Correção disponível
Serviços do Swarm contornam as restrições de segurança do ambiente
O Portainer verifica apenas parte da configuração ao criar um serviço do Docker Swarm e não aplica as restrições de segurança do ambiente ao atualizar esse serviço. Um acesso sem privilégios de administrador pode acrescentar capabilities elevadas, desativar o isolamento por Seccomp ou AppArmor e montar diretórios do host apesar das restrições configuradas. A inspeção também ignora opções do driver local que transformam um volume em uma montagem de diretório do host. A combinação desses recursos pode permitir acesso equivalente a root no host.
Casos de uso afetados
Você permite que acessos sem privilégios de administrador criem ou atualizem serviços no Swarm, mas restringe as capabilities e as montagens de diretórios do host nas configurações do ambiente.
Você desabilitou os bind mounts, porém permite criar volumes. As opções do driver local podem reproduzir essa montagem tanto nos serviços quanto na criação direta de volumes.
Confira na sua instância
Confira os acessos concedidos ao ambiente Swarm e as restrições habilitadas no Portainer. Nas especificações dos serviços, examine CapabilityAdd, Sysctls, Privileges e Mounts, inclusive as alterações feitas após a criação. Nas opções dos volumes locais, procure a combinação type: none e o: bind e confira qual diretório aparece em device. Compare qualquer montagem encontrada com as permissões concedidas ao acesso que criou ou alterou o recurso.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.33.x
>= 2.33.0, < 2.33.8
2.33.8
2.39.x
>= 2.39.0, < 2.39.2
2.39.2
2.40.x
>= 2.40.0, < 2.41.0
2.41.0
A revogação temporária do acesso ao Swarm para não administradores reduz a exposição. Separar as cargas dos nós manager limita as consequências de uma exploração em workers, mas não corrige a validação do Portainer.
Gravidade críticaCVSS: 9,4/10Correção disponível
Plugins Docker permitem executar código como root sem autorização administrativa
As rotas de gerenciamento de plugins Docker não possuem um handler de autorização no proxy do Portainer. As requisições seguem diretamente para o daemon, permitindo que um acesso sem privilégios de administrador, mas autorizado ao ambiente Docker, instale e habilite plugins. Como esses plugins executam com privilégios de root e podem utilizar capabilities elevadas e montagens do host, um plugin malicioso pode ler ou alterar arquivos do servidor.
Casos de uso afetados
Você concede acesso a um ambiente Docker pelo Portainer para implantar aplicações, mantendo o gerenciamento administrativo reservado.
O daemon Docker aceita instalar e habilitar plugins. Um acesso limitado ao ambiente pode utilizar essas rotas mesmo sem autorização administrativa no Portainer.
Confira na sua instância
Confira quais acessos sem privilégios de administrador podem utilizar cada ambiente Docker. No host, use docker plugin ls e examine os plugins encontrados com docker plugin inspect para revisar a origem, as capabilities e os diretórios montados. Nos logs HTTP disponíveis, procure chamadas às rotas /plugins/pull e /plugins/{name}/enable e compare os acessos envolvidos com as autorizações administrativas.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.33.x
>= 2.33.0, < 2.33.8
2.33.8
2.39.x
>= 2.39.0, < 2.39.2
2.39.2
2.40.x
>= 2.40.0, < 2.41.0
2.41.0
Revogar temporariamente o acesso aos ambientes Docker para não administradores remove o caminho descrito para esses acessos até a atualização. A restrição precisa ocorrer nas permissões do ambiente, pois ocultar ações na interface não corrige o encaminhamento das rotas.
Gravidade altaCVSS: 8,5/10Correção disponível
HostConfig.Mounts permite montar diretórios proibidos do host
A restrição de bind mounts para não administradores inspeciona HostConfig.Binds, mas ignora HostConfig.Mounts na criação de containers. O Docker aceita os dois campos para montar diretórios do host, então um acesso autorizado a criar containers pode usar o campo não verificado para ler ou alterar arquivos que deveriam permanecer inacessíveis. A montagem do socket Docker também permite acessar diretamente a API do daemon, fora das verificações do Portainer.
Casos de uso afetados
Você compartilha um ambiente Docker e permite criar containers com acessos limitados, confiando na opção que desabilita bind mounts para não administradores.
O host possui arquivos de credenciais ou volumes de outros containers. Uma montagem aceita pela falha pode expor esses arquivos conforme as permissões do daemon Docker.
Confira na sua instância
No ambiente afetado, confirme que a restrição de bind mounts está habilitada e identifique os acessos com permissão para criar containers. Use docker inspect nos containers criados por esses acessos e examine as montagens do tipo bind, com atenção ao diretório de origem e à possibilidade de escrita. Compare os resultados com os registros de criação e os logs disponíveis do daemon para identificar montagens incompatíveis com a restrição.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.33.x
>= 2.33.0, < 2.33.8
2.33.8
2.39.x
>= 2.39.0, < 2.39.2
2.39.2
2.40.x
>= 2.40.0, < 2.41.0
2.41.0
Este aviso trata da criação de containers pelo proxy da API Docker. A implantação de stacks pelo Compose segue outro caminho e não está incluída nesta falha. Retirar temporariamente a permissão de criar containers também interrompe as implantações que dependem dela.
Gravidade altaCVSS: 8,5/10Correção disponível
Links simbólicos em stacks Git expõem arquivos do Portainer
Ao obter o repositório de uma stack, o Portainer cria links simbólicos presentes no Git sem validar seus destinos. A leitura do arquivo da stack segue esses links e pode retornar um arquivo externo ao diretório do projeto. Um link com destino relativo pode alcançar arquivos legíveis pelo processo, como o banco do Portainer ou um token de acesso ao Kubernetes. A atualização automática permite introduzir o link em um commit posterior à revisão inicial do repositório.
Casos de uso afetados
Você permite implantar ou atualizar stacks a partir de repositórios Git que podem ser alterados por acessos sem privilégios de administrador.
Uma stack com atualização automática acompanha um repositório inicialmente legítimo. Uma alteração posterior substitui o arquivo de entrada por um link simbólico para fora do diretório da stack.
Confira na sua instância
Revise as stacks vinculadas ao Git e identifique quais utilizam atualização automática. No sistema de arquivos do container do Portainer, execute find /data/compose -type l, ajustando o caminho ao diretório configurado, e examine os destinos encontrados sem abrir arquivos sensíveis. Confira especialmente se docker-compose.yml é um link e se seu destino relativo sai do diretório do projeto. Revise o histórico do repositório associado para localizar a alteração.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.33.x
>= 2.33.0, < 2.33.8
2.33.8
2.39.x
>= 2.39.0, < 2.39.2
2.39.2
2.40.x
>= 2.40.0, < 2.41.0
2.41.0
Desabilitar a atualização automática remove a possibilidade de introduzir o link por essa rotina, mas a criação ou atualização manual continua exposta. Restringir o gerenciamento de stacks a administradores também mantém a exposição a repositórios maliciosos utilizados por esses administradores.
Gravidade altaCVSS: 8,1/10Correção disponível
Falha na validação do token não encerra o acesso ao Kubernetes
O middleware do proxy Kubernetes escreve uma resposta HTTP 403 quando a validação secundária do token falha, mas continua a execução porque falta um retorno naquele ponto. Segundo o comunicado, uma sessão válida do Portainer pode alcançar recursos de um ambiente Kubernetes apesar da autorização recusada. A leitura ou alteração de recursos depende das permissões que o Portainer possui no cluster. O defeito aparece nas edições Community e Enterprise.
Casos de uso afetados
Você administra clusters Kubernetes pelo Portainer e distribui permissões diferentes de acesso aos ambientes entre as sessões autenticadas.
A credencial utilizada pelo Portainer no cluster permite ler secrets ou alterar deployments. Esses privilégios ampliam as consequências de uma requisição encaminhada indevidamente.
Confira na sua instância
Compare as permissões dos ambientes Kubernetes no Portainer com as permissões da credencial utilizada no cluster. Nos logs disponíveis, relacione respostas 403 do proxy com os registros de auditoria do Kubernetes para identificar requisições que chegaram ao cluster apesar da recusa. A resposta 403 isolada não confirma que o processamento terminou. Confira se a instância executa 2.33.8 na linha afetada.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.33.x
>= 2.33.0, < 2.33.8
2.33.8
O aviso informa que a versão 2.39.0 já contém a correção. Limitar as permissões da credencial do Portainer no Kubernetes reduz os recursos alcançáveis, mas não corrige a continuidade indevida do middleware.
Gravidade altaCVSS: 7,7/10Correção disponível
Tokens de sessão na URL podem vazar pelos logs e pelo navegador
O Portainer aceita o token JWT de sessão no campo token da URL, além do cabeçalho Authorization. Essa URL pode ficar registrada no proxy reverso e no histórico do navegador ou ser transmitida pelo cabeçalho Referer. Um invasor que obtenha um token ainda válido consegue usar as permissões da sessão correspondente sem conhecer a senha. Os recursos de console de containers e shell de pods utilizavam esse formato, expondo também sessões sem privilégios de administrador.
Casos de uso afetados
Você abre o console de um container ou o shell de um pod pelo navegador e o proxy reverso registra a URL completa das conexões.
Uma URL do Portainer com token de sessão foi compartilhada em uma conversa ou chamado de suporte. O acesso concedido pelo token permanece utilizável durante sua validade.
Confira na sua instância
Procure ocorrências de ?token= e &token= nos logs do proxy reverso e da aplicação, sem copiar os valores encontrados para chamados ou relatórios. Identifique as sessões expostas e redefina as senhas correspondentes conforme a orientação do comunicado. Após atualizar, confira nas requisições do navegador se o console utiliza o cookie HttpOnly portainer_api_key e se os clientes da API enviam a autenticação pelo cabeçalho Authorization.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.33.x
>= 2.33.0, < 2.33.8
2.33.8
2.39.x
>= 2.39.0, < 2.39.2
2.39.2
2.40.x
>= 2.40.0, < 2.41.0
2.41.0
Remover o campo token no proxy reverso interrompe a autenticação por URL, mas também pode interromper os consoles interativos nas versões vulneráveis. O comunicado informa validade padrão de oito horas para a sessão, configurável na instância.
Gravidade moderadaCVSS: 6,0/10Correção disponível
Arquivos de templates privados ficam acessíveis a qualquer sessão autenticada
A rota GET /api/custom_templates/{id}/file retorna o arquivo de um template personalizado sem verificar a autorização sobre aquele recurso. Os identificadores numéricos sequenciais permitem localizar templates que não aparecem na listagem de um acesso limitado. Quando o arquivo contém uma senha de banco ou um token de integração, esse segredo fica exposto mesmo que você tenha restringido o template a outros acessos.
Casos de uso afetados
Você mantém templates personalizados privados para implantar serviços e incluiu credenciais diretamente nos arquivos de configuração.
A instância possui pelo menos um template personalizado e aceita sessões autenticadas com permissões limitadas. A restrição da listagem não se aplica à leitura do arquivo pela rota afetada.
Confira na sua instância
Com acesso administrativo, revise o conteúdo de todos os templates personalizados, inclusive os privados, e procure credenciais inseridas diretamente nos arquivos. Nos logs HTTP disponíveis, examine os acessos a /api/custom_templates/{id}/file e compare os identificadores consultados com as autorizações dos templates. Confira especialmente a versão da linha 2.39.x, pois a correção deste aviso chegou em 2.39.1.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.33.x
>= 2.33.0, < 2.33.8
2.33.8
2.39.x
>= 2.39.0, < 2.39.1
2.39.1
O comunicado informa que a versão 2.40.0 já contém a correção. Substitua os segredos armazenados em templates de uma instância vulnerável, pois a atualização não desfaz uma exposição anterior.
Gravidade moderadaCVSS: 5,5/10Correção disponível
Restauração de backup pode escrever fora do diretório de destino
A extração do backup combina o diretório de destino com os nomes presentes no arquivo .tar.gz sem conferir se o caminho resultante permanece dentro desse diretório. Uma entrada com componentes ../ pode direcionar a escrita para outro local acessível ao processo do Portainer. A exploração exige acesso administrativo à restauração ou que você, como administrador, restaure um arquivo malicioso. O alcance no host depende dos diretórios disponíveis dentro do container.
Casos de uso afetados
Você utiliza a restauração de backups na linha 2.33.x afetada e recebe arquivos de terceiros para recuperar uma instância.
O container do Portainer possui diretórios do host montados com permissão de escrita. Um backup malicioso pode alcançar esses locais se o caminho produzido pela extração apontar para eles.
Confira na sua instância
Confira a versão que executa a restauração e a procedência dos backups utilizados. Para arquivos .tar.gz não criptografados, examine os nomes das entradas com tar -tzf, sem extrair, e procure componentes ../ que escapem do destino. Revise também as montagens graváveis do container para entender quais diretórios externos o processo consegue alcançar.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.33.x
>= 2.33.0, < 2.33.8
2.33.8
A versão 2.39.0 já contém a correção. Restaurar somente backups de origem confiável e utilizar a criptografia oferecida pelo Portainer são medidas temporárias, que não substituem a atualização.
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.
