EN PT-BR
← Voltar ao feed
high

rsync 3.5.2 Patches CVE-2026-119741, a CPU Exhaustion Flaw in Checksum Matching

1 fonte(s) · 1 atualização(ões) · publicado 04/11/2026 04:43 · coletado há 1 hora

The rsync project released version 3.5.2, fixing CVE-2026-119741, a vulnerability in the hash_search() function in match.c that allows a malicious receiving client to exhaust a server's CPU during file synchronization. All versions through 3.5.1 are affected. The flaw was assigned by VulnCheck, which rates it 8.7 on CVSS 4.0 and 7.5 on CVSS 3.1, with impact limited to availability. Public rsync daemon modules that allow anonymous pulls are especially exposed since no authentication is required to trigger the condition.

Entenda a falha

A vulnerabilidade

CVE-2026-119741 is an algorithmic-complexity flaw in rsync's hash_search() function in match.c. A malicious receiving client can force the sender to burn CPU on useless strong-checksum computations, so a few concurrent connections can exhaust the server's CPU. Public rsync daemon modules that allow anonymous pulls need no authentication to trigger it. Impact is availability only (CVSS 4.0 8.7, CVSS 3.1 7.5, as scored by VulnCheck, which assigned the ID). All versions through 3.5.1 are affected; 3.5.2 fixes it.

Como funciona

In a transfer, the receiver cuts its copy of a file into blocks and sends the sender a cheap rolling checksum and a stronger checksum for each block. The sender slides a window across its own copy, checks the weak checksum first and, on a weak match, computes the strong checksum to confirm the block is identical. The problem appears at that confirmation step: a malicious receiver sends weak checksums that keep colliding with window after window, paired with strong checksums that never match. The sender keeps computing strong checksums that fail, wasting CPU.

Por que é vulnerável

The matching loop trusts the receiver's checksums and does not bound the strong-checksum work that a stream of weak collisions can trigger. VulnCheck classifies it as inefficient algorithmic complexity. The articles do not describe exactly how 3.5.2 changes hash_search() to fix it, nor why it went unnoticed.

Onde está

The hash_search() function in match.c.

Como foi descoberta

The articles do not say who found the flaw or how. They say only that VulnCheck assigned the CVE ID and scored it, and that the rsync project disclosed it with the release of version 3.5.2 on 2026-11-04.

Explicação gerada por IA a partir da matéria e dos artigos, em 04/11/2026 05:17.

Detalhes técnicos

During a transfer, the receiver splits its file copy into blocks and sends a weak rolling checksum plus a stronger checksum for each. The sender slides a matching window across its own copy, first checking the weak checksum, then computing the strong one to confirm a match. A malicious receiver can send weak checksums that repeatedly collide across rolling windows while pairing them with strong checksums that never match, forcing the sender into continuous, wasted strong-checksum computation. A handful of concurrent connections can exhaust CPU resources entirely. The condition affects only availability, not data confidentiality or integrity.

Remediação

Upgrade to rsync 3.5.2, which fixes the checksum-matching flaw and also introduces --nice and --no-nice options to set CPU and I/O scheduling priority for local and/or remote processes, including support in rrsync (the restricted SSH wrapper), helping limit resource contention from large transfers.

Linha do tempo

  1. helpnetsecurity.com ↗ · pub. 04/11/2026 04:43 · coletado 04/11 05:01 primeiro registro

    rsync 3.5.2 Patches CVE-2026-119741, a CPU Exhaustion Flaw in Checksum Matching

    ler a análise desta fonte

    The rsync project released version 3.5.2, fixing CVE-2026-119741, a vulnerability in the hash_search() function in match.c that allows a malicious receiving client to exhaust a server's CPU during file synchronization. All versions through 3.5.1 are affected. The flaw was assigned by VulnCheck, which rates it 8.7 on CVSS 4.0 and 7.5 on CVSS 3.1, with impact limited to availability. Public rsync daemon modules that allow anonymous pulls are especially exposed since no authentication is required to trigger the condition.

    Technical Details

    During a transfer, the receiver splits its file copy into blocks and sends a weak rolling checksum plus a stronger checksum for each. The sender slides a matching window across its own copy, first checking the weak checksum, then computing the strong one to confirm a match. A malicious receiver can send weak checksums that repeatedly collide across rolling windows while pairing them with strong checksums that never match, forcing the sender into continuous, wasted strong-checksum computation. A handful of concurrent connections can exhaust CPU resources entirely. The condition affects only availability, not data confidentiality or integrity.

    Remediation

    Upgrade to rsync 3.5.2, which fixes the checksum-matching flaw and also introduces --nice and --no-nice options to set CPU and I/O scheduling priority for local and/or remote processes, including support in rrsync (the restricted SSH wrapper), helping limit resource contention from large transfers.