libssh2: falha CVSS 9.2 no SSH tem exploit público e RCE

Q: O que é a falha CVE-2026-55200?

A biblioteca libssh2 é um cliente SSH. É o detalhe mais importante de toda essa história: não é um servidor exposto que você precisa defender — é o código que roda no lado de quem conecta . Ela está embutida em curl, Git, PHP, agentes de backup, atualizadores de firmware e numa cauda longa de eletrodomésticos de rede. Qualquer coisa que a linka estaticamente e fala com um servidor SSH não confiável é alvo em potencial. O bug mora na função ssh2_transport_read() , dentro de transport.c , que analisa os pacotes SSH recebidos durante o handshake. O código lia o campo packet_length controlado pelo atacante e só rejeitava valores abaixo de 1. Nunca impunha um limite superior . A conta de tamanho soma esse comprimento a pequenos valores usando aritmética de 32 bits, então um packet_length de 0xffffffff dá a volta (wrap) e vira um número minúsculo. A libssh2 aloca um buffer do tamanho do número minúsculo — e o código seguinte escreve o pacote inteiro, gigante, por cima. Resultado: escrita fora dos limites no heap, classificada como CWE-680 (estouro de inteiro que vaza para buffer overflow), um primitivo clássico de execução de código. A correção adiciona a verificação que faltava, rejeita

A falha CVE-2026-55200, classificada como CVSS 9.2, deixa a biblioteca libssh2 — usada por curl, Git, PHP e milhares de aplicações e appliances — vulnerável à execução remota de código. Basta o cliente conectar a um servidor SSH malicioso ou comprometido para que a memória seja corrompida, sem senha e sem clique. Já existe prova de conceito pública.

Pontos-chave

O que é: estouro de inteiro que vira buffer overflow no ssh2_transport_read() da libssh2, na fase de handshake.
Severidade: CVSS 4.0 de 9,2; afeta todas as versões até a 1.11.1, pré-autenticação.
Impacto real: execução remota de código num cliente que só conectou ao servidor errado.
Já explorável: há prova de conceito pública no repositório “exploitarium”, com servidor SSH malicioso em Python.
O que fazer: aplicar build com o commit 97acf3d, mapear cópias estáticas e restringir SSH de saída.

O que é a falha CVE-2026-55200

A biblioteca libssh2 é um cliente SSH. É o detalhe mais importante de toda essa história: não é um servidor exposto que você precisa defender — é o código que roda no lado de quem conecta. Ela está embutida em curl, Git, PHP, agentes de backup, atualizadores de firmware e numa cauda longa de eletrodomésticos de rede. Qualquer coisa que a linka estaticamente e fala com um servidor SSH não confiável é alvo em potencial.

O bug mora na função ssh2_transport_read(), dentro de transport.c, que analisa os pacotes SSH recebidos durante o handshake. O código lia o campo packet_length controlado pelo atacante e só rejeitava valores abaixo de 1. Nunca impunha um limite superior. A conta de tamanho soma esse comprimento a pequenos valores usando aritmética de 32 bits, então um packet_length de 0xffffffff dá a volta (wrap) e vira um número minúsculo. A libssh2 aloca um buffer do tamanho do número minúsculo — e o código seguinte escreve o pacote inteiro, gigante, por cima. Resultado: escrita fora dos limites no heap, classificada como CWE-680 (estouro de inteiro que vaza para buffer overflow), um primitivo clássico de execução de código.

A correção adiciona a verificação que faltava, rejeitando qualquer packet_length acima de LIBSSH2_PACKET_MAXPAYLOAD antes da matemática rodar. A nota técnica do CyberSec Guru confirma a localização exata e o commit que resolve.

Como o ataque na prática funciona

Não precisa de credenciais, não precisa de interação humana. O gatilho é pré-autenticação. A pesquisadora e o pesquisador que revisam o caso descrevem dois caminhos realistas: um servidor SSH malicioso (se você conectar em algo comprometido) ou um ataque man-in-the-middle posicionado no caminho de rede, que injeta o pacote forjado na sessão criptografada. O fórum da Purism resume o cenário em uma frase: “explorável por MITM ou por servidor malicioso”.

Para entender a mecânica sem ruído, vale uma tabela com os elementos que tornam o bug perigoso:

Elemento	Detalhe
Vetor	Servidor SSH malicioso ou MITM no caminho da rede
Autenticação necessária	Nenhuma (gatilho pré-handshake)
Primitivo resultante	Escrita fora dos limites no heap
Consequência máxima	Execução remota de código no cliente
Versões afetadas	Todas até 1.11.1 (inclusive)
Correção	Commit 97acf3d (guard de packet_length)

Atingir execução de código confiável contra uma aplicação real ainda depende do binário-alvo, do comportamento do alocador, das mitigações (ASLR, canários) e de como o programa incorpora a libssh2. O PoC não é um botão mágico de invasão. Mas, para uma falha de CVSS 9,2 sem necessidade de senha, a margem é perigosamente curta.

Quais sistemas estão em risco

O problema escuro dessa falha é a invisibilidade. Muitas cópias da libssh2 são linkadas estaticamente dentro de binários maiores. Uma atualização de pacote da sua distribuição não vai tocá-las — e você pode nem saber que elas existem. O The Hacker News é taxativo: curl, Git e deploys de PHP são portadores comuns.

No contexto brasileiro, isso importa por dois motivos concretos. Primeiro, a maioria das hospedagens WordPress nacionais roda PHP com curl por baixo — um alvo que combina volume e exposição (e o próprio curl tem histórico recente de falhas críticas corrigidas). Segundo, SSH é onipresente em fintechs, bancos, startups e prestadoras de infraestrutura, onde scripts de automação conectam a dezenas de servidores diariamente. Se um desses destinos estiver comprometido, ou se o DNS/redirecionamento de tráfego puder ser manipulado, o cliente que “só” fez a conexão já é uma vítima potencial.

Appliances de rede, atualizadores de firmware embutidos em câmeras, roteadores e equipamentos de backup corporativo completam a lista. A Cybersecurity News cita explicitamente agentes de backup, atualizadores de firmware e dispositivos embarcados como componentes que linkam a biblioteca. O padrão é o mesmo de outros ataques recentes que abusam de ferramentas de confiança do desenvolvedor — como o caso em que abrir um repositório malicioso vazava chaves da AWS.

Leia também: para entender como uma única falha de execução remota de código escala para invasão real, vale revisar o caso em que um RCE no Langflow instalava cryptominer em aplicações de IA.

O exploit público muda tudo

O pesquisador Tristan Madani reportou a falha; mantenedores mesclaram o patch pelo pull request #2052 em 12 de junho de 2026, e a VulnCheck publicou o CVE no dia 17. Mas a virada de jogo veio depois: uma prova de conceito foi publicada no repositório “exploitarium”, no GitHub, um arquivo de código de exploit cujo autor diz ter divulgado as entradas sem reporte prévio.

O pacote não é um exploit pronto para qualquer alvo. Ele traz três peças: um verificador em C11 que reproduz a aritmética vulnerável e prova o estouro de inteiro, um servidor SSH malicioso mínimo em Python que negocia a sessão criptografada e entrega o pacote forjado, e um harness local de RCE que demonstra o controle de execução sobrevivendo do buffer para um ponteiro de callback. A descrição técnica deixa claro: a estrutura confirma a viabilidade da execução de código, mas transformá-la em ataque confiável contra serviços reais depende de fatores específicos de cada alvo.

Ainda assim, com código funcional disponível, a janela de risco encolhe. A classificação da CISA de exploração em campo segue como nenhuma por enquanto, sem uso confirmado na natureza. A pergunta aberta não é se alguém vai converter o harness local em exploit remoto confiável — é quando.

O fantasma de 2019 reaparece

O mais perturbador na CVE-2026-55200 é o déjà vu. Em 2019, a libssh2 lançou a versão 1.8.1 para corrigir um lote de nove falhas, liderado pela CVE-2019-3855: um estouro de inteiro quase idêntico, na mesma função de leitura de transporte, que também permitia a um servidor malicioso rodar código no cliente conectado. Sete anos depois, a mesma classe de bug voltou no mesmo código.

Isso diz algo desconfortável sobre a manutenção de bibliotecas fundamentais que quase ninguém vê. A libssh2 não tem rosto de produto — não aparece em capas de revista de tecnologia. Mas está embaixo de pilhas de software que todos usam. Quando o mesmo erro estrutural retorna no mesmo arquivo após meia década, o problema não é o bug isolado: é que a auditoria defensiva desse código nunca foi prioridade.

A mesma remessa ainda traz outras duas falhas que merecem correção conjunta: a CVE-2026-55199 (CVSS 8,2), uma negação de serviço que prende o cliente num loop de CPU com uma contagem de extensão falsa, e a CVE-2025-15661 (CVSS 8,3), uma leitura além do limite no heap do SFTP.

Como se proteger agora mesmo

Não existe release nova da libssh2 com o patch ainda; ele está no código-fonte da linha principal e um release tagueado está em preparação. Distribuições e projetos downstream estão fazendo o backport por conta própria. A Debian, por exemplo, já tem um build corrigido em teste, e a NHS England Digital emitiu um aviso pedindo que organizações afetadas atualizem.

Faça inventário real. Mapeie tudo que linka libssh2, inclusive cópias estáticas ou embaladas que o gerenciador de pacotes não sinaliza. curl, Git e PHP são os primeiros suspeitos.
Aplique a build corrigida. Use uma versão que inclua o commit 97acf3d — seja o backport da distro, seja um build de fonte corrigido. Acompanhe o canal de avisos do seu fornecedor.
Restrinja SSH de saída. Até corrigir, limite conexões SSH outbound a servidores confiáveis e verifique host keys. Priorize clientes que falam com SSH externo ou que resolvem nomes que um atacante possa redirecionar.
Monitore anomalias. Fique de olho em pacotes fora de tamanho e em falhas de cliente inexplicáveis — sinais de tentativa de exploração.
Corrija o resto do lote. Não se esqueça da CVE-2026-55199 e da CVE-2025-15661 na mesma atualização.