OpenSSH 10.5 corrige CVE-2026-73281 no ssh-agent e agent forwarding

O OpenSSH 10.5 corrigiu a CVE-2026-73281, uma interação incorreta entre o bloqueio do ssh-agent e a extensão que vincula uma sessão a um agente encaminhado. Em condições específicas, operações destinadas ao uso somente local podiam ser realizadas remotamente, inclusive adicionar tokens PKCS#11 ou usar chaves com restrições de destino.

O que aconteceu

O ssh-agent guarda chaves em memória e assina desafios sem entregar a chave privada ao servidor remoto. Com agent forwarding, uma sessão remota pode pedir assinaturas ao agente que continua na máquina de origem. Isso é conveniente para saltos administrativos, mas amplia a confiança: root no host intermediário ou um processo comprometido pode conversar com o agente enquanto ele estiver encaminhado.

O OpenSSH usa session-bind@openssh.com para identificar o caminho da sessão e aplicar restrições de destino. Quando o agente estava bloqueado, certos pedidos de vínculo eram recusados. O efeito inesperado era que algumas operações que deveriam continuar locais podiam ser acionadas remotamente. A versão 10.5 corrige esse comportamento.

Versões afetadas e corrigidas

Em CloudLinux, AlmaLinux, Debian, Ubuntu e outras distribuições corporativas, não conclua pela comparação simples com 10.5. Os mantenedores podem portar o patch para um pacote com número upstream menor. A evidência correta é o changelog e o advisory do pacote da distribuição.

Nível de risco e pré-condições

A CNA atribuiu CVSS 3.1 de 3,5, portanto o risco base é baixo. Ele cresce para administradores que usam agent forwarding através de bastions ou servidores que não controlam integralmente. O cenário requer privilégios baixos no ambiente remoto, complexidade alta e uma configuração de agente encaminhado; o impacto principal é de integridade, por uso de operações ou chaves fora do destino pretendido.

Servidores que apenas executam sshd e nunca recebem agente encaminhado não possuem a mesma rota prática. Ainda assim, clientes, estações administrativas e jump hosts também fazem parte do inventário: corrigir apenas o daemon do servidor pode deixar o ssh-agent vulnerável na origem.

Como verificar a exposição

Confira a versão do cliente e do servidor:

ssh -V
sshd -V 2>&1
rpm -q openssh openssh-clients openssh-server 2>/dev/null
dpkg-query -W 'openssh-client' 'openssh-server' 2>/dev/null

Procure encaminhamento habilitado na configuração efetiva e nos arquivos do usuário:

sshd -T | grep -i allowagentforwarding
ssh -G servidor-exemplo | grep -i forwardagent
grep -Rni '^[[:space:]]*ForwardAgent' /etc/ssh/ssh_config /etc/ssh/ssh_config.d ~/.ssh/config 2>/dev/null

Dentro de uma sessão SSH, test -n "$SSH_AUTH_SOCK" && echo agente-encaminhado indica que um socket de agente está disponível. Isso não prova exploração, mas confirma a pré-condição operacional. Inventarie também aplicações que iniciam SSH de forma automática e plugins que ativam forwarding.

Como corrigir e reduzir o risco

1. instale o pacote de segurança publicado pela distribuição e confirme o changelog;
2. reinicie sessões e processos ssh-agent antigos após atualizar;
3. desative ForwardAgent por padrão e habilite somente para destinos necessários;
4. prefira ProxyJump, chaves separadas e restrições de destino;
5. não encaminhe agentes a servidores compartilhados ou de confiança limitada;
6. mantenha tokens PKCS#11 e chaves de alto valor fora de fluxos genéricos.

Medidas adotadas pela WebinHost

A resposta inclui revisar pacotes OpenSSH e políticas de agent forwarding na camada de servidor administrada. A WebinHost recomenda chaves individuais, autenticação forte, origem restrita no firewall e ausência de forwarding global. A atualização de estações locais e agentes iniciados pelo usuário continua sob responsabilidade de quem administra esses dispositivos.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Tutoriais, downloads e serviços relacionados

Use estes materiais para continuar a verificação com segurança:

Referências oficiais

• OpenSSH — release notes 10.5
• oss-security — anúncio do OpenSSH 10.5 pelos mantenedores
• CVE.org — CVE-2026-73281

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.