rsync 3.5.2 corrige CVE-2026-119741: cliente malicioso esgota a CPU do servidor na checagem de checksum

Quem mantém um servidor rsync, principalmente um daemon com módulo público de pull anônimo, deve atualizar para a versão 3.5.2. O projeto corrigiu a CVE-2026-119741, que permite a um cliente receptor malicioso consumir a CPU do servidor com cálculos de checksum inúteis. Todas as versões até a 3.5.1 são afetadas, segundo o Help Net Security.

Como o rsync verifica os blocos

O rsync copia arquivos localmente e pela rede e é muito usado em espelhos de repositórios de software e em backups. Para transferir pouco dado, ele envia só as partes que mudaram.

O lado receptor divide a sua cópia do arquivo em blocos. Para cada bloco, ele manda ao emissor um checksum fraco (rolling) e um checksum forte. O emissor desliza uma janela sobre a sua própria cópia, compara primeiro o checksum fraco e, se houver coincidência, calcula o forte para confirmar que o bloco é idêntico.

Onde está a falha

A CVE-2026-119741 está na função hash_search(), no arquivo match.c. É uma falha de complexidade algorítmica. Um receptor malicioso envia checksums fracos que colidem em janelas sucessivas, combinados com checksums fortes que nunca correspondem. O emissor continua calculando checksums fortes que sempre falham.

Segundo o relato, poucas conexões simultâneas bastam para esgotar a CPU do servidor.

A VulnCheck, que atribuiu o ID, classifica o problema como complexidade algorítmica ineficiente. A pontuação é 8,7 no CVSS 4.0 e 7,5 no CVSS 3.1. O impacto é só de disponibilidade, sem efeito sobre confidencialidade ou integridade dos dados.

Quem está mais exposto

O caso mais crítico é o de módulos públicos de daemon rsync que permitem pull anônimo. Nesse cenário, o atacante não precisa de conta, porque baixar arquivos é justamente a função do módulo. Servidores que exigem autenticação também são afetados nas versões até a 3.5.1, mas o ataque passa a depender de um cliente autorizado a conectar.

O que mudou na 3.5.2

Além de corrigir a lógica de correspondência de checksum, a versão 3.5.2 traz as opções --nice e --no-nice. Elas definem a prioridade de escalonamento de CPU e de I/O do processo local, do remoto ou de ambos, e os dois valores são independentes.

Para daemons, um cliente pode pedir apenas CPU com nice 19, prioridade de I/O ociosa, ou os dois. O rrsync, o wrapper SSH restrito, aceita apenas reduções locais. Quando uma mudança local não é suportada ou é negada, o rsync avisa e a transferência continua. Ajustes remotos exigem um par com suporte, e os ajustes só locais funcionam contra pares mais antigos.

O artigo apresenta essas opções como forma de evitar que uma sincronização grande atrapalhe o resto da máquina. Elas não são descritas como mitigação da CVE. A correção é a atualização.

O que verificar

1. Veja a versão instalada em cada servidor que envia arquivos por rsync:

rsync --version

2. Se for 3.5.1 ou anterior, atualize para a 3.5.2. Em distribuições com pacote próprio, confira se o pacote já incorpora a correção, pois o número de versão do pacote pode diferir do upstream.
3. Liste os servidores que rodam o rsync como daemon e identifique quais módulos aceitam pull anônimo. Eles são a prioridade.
4. Inclua espelhos e hosts de backup que você não costuma lembrar. O rsync costuma ficar esquecido em scripts e crons.
5. Se não puder atualizar agora, avalie restringir o acesso ao daemon por firewall a clientes conhecidos. Essa é uma medida de redução de exposição minha, e o artigo não a cita.
6. Em picos de CPU sem explicação em servidores rsync, olhe os processos do rsync e o número de conexões simultâneas ao daemon.

Fontes: Help Net Security