O projeto OpenSSH lançou as versões 10.3 e 10.3p1 em 2 de abril de 2026, abordando uma vulnerabilidade de injeção de shell e introduzindo várias alterações de endurecimento de segurança que os administradores devem revisar antes de atualizar.
Vulnerabilidade de injeção de shell no ProxyJump
A correção de segurança mais notável visa uma vulnerabilidade de injeção de shell na opção de linha de comando -J (ProxyJump). Antes desta versão, nomes de usuário e host passados via -J ou -oProxyJump="..." na linha de comando não eram validados, criando uma oportunidade para injeção de shell se esses valores fossem diretamente originados de entrada adversária.
A falha foi relatada por um pesquisador identificado como "rabbit." Os desenvolvedores do OpenSSH observam que expor essas opções a entrada não confiável "teria sido uma ideia terrível desde o início", mas a correção garante que valores maliciosos ou malformados sejam rejeitados na etapa de validação. Importante notar que essa validação se aplica apenas ao uso de linha de comando; entradas de arquivo de configuração permanecem não validadas.
Mudanças no manuseio de certificados SSH
Um comportamento sutil, mas potencialmente arriscado, no manuseio de certificados sshd também foi corrigido. Anteriormente, certificados SSH emitidos com uma seção de principais vazia eram tratados como um curinga, efetivamente permitindo autenticação como qualquer usuário que confiava na Autoridade Certificadora (CA) emissora via authorized_keys.
Esse comportamento era intencional por design, mas criou um caso de borda perigoso: se uma CA acidentalmente emitisse um certificado sem principais definidos, poderia ser explorado para acesso não autorizado amplo.
O OpenSSH 10.3 altera esse comportamento para que uma seção de principais vazia nunca corresponda a nenhum principal, eliminando o risco de curinga acidental. Além disso, caracteres curinga em principais de certificado são agora consistentemente aplicados e suportados para certificados de host, mas explicitamente não suportados para certificados de usuário, trazendo controles de acesso mais claros e previsíveis.
Requisitos de rekeying de transporte
O OpenSSH também eliminou a compatibilidade retroativa para implementações SSH que não suportam rekeying de camada de transporte. Qualquer cliente ou servidor SSH legado que não possa lidar com rekeying falhará eventualmente ao interoperar com o OpenSSH quando o transporte exigir um rekey.
Essa alteração reforça a conformidade do protocolo e remove uma solução alternativa de longa data que poderia enfraquecer garantias de segurança em sessões de longa duração.
Recomendações para equipes de segurança
Equipes de segurança executando infraestrutura SSH devem priorizar essa atualização, especialmente em ambientes onde as opções ProxyJump são construídas programaticamente ou originadas de entrada de usuário. A alteração de comportamento do principal do certificado também pode exigir uma revisão de certificados emitidos por CA existentes para garantir que nenhum carregue campos de principal vazios.
Perguntas frequentes
- Qual é a severidade da vulnerabilidade de injeção de shell? Alta, permitindo execução de comandos arbitrários.
- Quais versões são afetadas? Versões anteriores ao 10.3.
- Como mitigar antes da atualização? Evitar uso de ProxyJump com entrada não confiável e revisar certificados de CA.