O Portainer 2.45.3 deixa de confiar em certificados digitais emitidos pela eMudhra, também identificada como emSign. A mudança pode interromper o login e as conexões com serviços externos que apresentem certificados afetados. Por isso, o alerta central desta versão, publicada em 21 de outubro de 2026, é verificar essas dependências antes de atualizar.
Certificados afetados podem impedir o login e o acesso a repositórios
Um certificado digital funciona como uma identificação apresentada por um serviço durante uma conexão protegida. Para aceitar essa identificação, o Portainer precisa confiar nas entidades que a emitiram. Nesta versão, essa confiança muda após o comprometimento de oito autoridades certificadoras intermediárias da eMudhra.
O Portainer remove os certificados raiz emSign do conjunto de autoridades confiáveis nas imagens Linux e rejeita cadeias de certificados que contenham as intermediárias comprometidas. Conforme o aviso do projeto, conexões com serviços que apresentem um certificado afetado falharão após a atualização.
Isso inclui provedores de login OAuth/OIDC, usados para autenticação com uma conta externa, e LDAPS, que permite consultar um diretório de usuários por uma conexão protegida. Também podem ser afetados os registros de imagens de contêineres e os servidores Git dos quais o Portainer obtém arquivos de implantação.
Se o provedor de login único ou LDAP estiver entre os afetados, somente o administrador inicial conseguirá entrar no Portainer, segundo a nota da versão. A restrição não é descrita como acesso garantido para qualquer conta administrativa.
Antes da atualização, a orientação do projeto é conferir os serviços utilizados. Como preparação prática, vale pedir ao responsável por essas integrações que verifique os certificados dos provedores de autenticação, registros de imagens e servidores Git. Esse cuidado não significa que toda instalação será afetada: o risco descrito depende dos certificados apresentados pelos serviços conectados.
Restrições para montagem de pastas e credenciais do Kubernetes
Quando a opção Hide bind mounts for non-administrators, que oculta montagens de pastas do servidor para usuários não administradores, está ativada, o Portainer passa a rejeitar determinadas operações com conjuntos de contêineres Compose e Swarm que usam volumes_from. A restrição vale quando um não administrador tenta criar, atualizar, iniciar ou reimplantar esses conjuntos.
O motivo é que volumes_from permitia herdar as montagens de outro contêiner, incluindo pastas do servidor que a configuração pretendia ocultar. A mudança é condicionada à opção estar ativada e às operações realizadas por não administradores; não é uma proibição geral desse recurso em todas as situações.
No Kubernetes, os tokens presentes no kubeconfig, arquivo que reúne dados de conexão e autenticação, ficam restritos ao intermediário de acesso do Portainer para Kubernetes, na rota /api/endpoints/{id}/kubernetes. Tentativas de usá-los em outras rotas da API passam a ser recusadas com o código 403, que indica acesso negado. Isso inclui rotas administrativas e o intermediário de acesso ao Docker.
Os arquivos kubeconfig baixados depois da atualização também passam a trazer um token separado por ambiente, limitado àquele ambiente. Essa condição sobre novos downloads é importante: a nota não afirma que arquivos já baixados são reemitidos automaticamente.
GitOps evita consultas sobrepostas e registra o estado após reimplantação manual
Nos fluxos GitOps, o Portainer consulta um repositório Git para acompanhar definições de implantação. Antes da correção, uma nova consulta agendada podia começar enquanto a anterior ainda estava em andamento, acumulando reimplantações sobrepostas em repositórios lentos. Agora, se uma consulta ainda estiver rodando, a próxima consulta prevista é pulada.
Outra correção trata das informações exibidas depois de uma reimplantação manual a partir do Git. A referência do Git e o estado do caminho do arquivo podiam aparecer como desconhecidos. A operação manual passa a registrar esses estados no registro do fluxo associado ao conjunto de contêineres.
Correções no Docker, na busca de registros e na interface
A versão corrige a falha que retornava erro 400 ao iniciar um contêiner com uma solicitação sem conteúdo, em ambientes Docker independentes e em ambientes Swarm com agente. Também corrige a consulta aos limites de obtenção de imagens do Docker Hub e a identificação da versão do agente em mecanismos Docker com API superior à 1.47.
Há ainda uma correção específica da Business Edition, ou BE: usuários não administradores com acesso ao ambiente podiam receber erros 403 nas rotas /agent/docker e /agent/host, deixando vazios os seletores de nós do Swarm. Esse ajuste não deve ser entendido como uma mudança documentada para a Community Edition.
Na interface, a busca dos registros de autenticação volta a filtrar eventos pelo nome de usuário. A aba YAML dos detalhes de um nó Kubernetes também deixa de ficar em branco após alternar abas ou voltar o foco ao navegador, e o espaçamento ausente entre seu conteúdo e a tabela de aplicações é restaurado.
Async Edge e Podman continuam com limitações conhecidas
A lista de problemas conhecidos é separada das correções. Em ambientes Async Edge, ainda pode aparecer uma data inválida de agendamento de atualização ao consultar um retrato do ambiente, chamado de snapshot.
Para Podman, o script de inclusão automática de ambientes continua sem suporte. Também permanece a impossibilidade de adicionar um ambiente Podman por socket, o canal local de comunicação, quando o servidor Portainer roda em Docker, e vice-versa. O suporte informado se limita a CentOS 9 com Podman 5 em modo rootful, isto é, executado com privilégios de administrador do sistema.
Além dos pontos explicados aqui, a versão atualiza componentes internos para corrigir vulnerabilidades. Esta seleção não reproduz todas as correções nem todos os identificadores de segurança da release; o aviso sobre certificados merece atenção prévia porque pode alterar diretamente o acesso ao Portainer e às suas integrações.