Skip to content

GHSA-rjvj-qgqg-cvx9 on CTRL-OS 26.05

Aliases: GHSA-rjvj-qgqg-cvx9, CVE-2026-70455

Packages: rsync

Status: Plausible

Advisory Information

A daemon client controls the server-side sender arguments, so a client naming a large --compress-threads (short form --zt) on a PULL makes the daemon-side sender materialise that many Zstandard workers -- 256 was measured as 257 threads in a single connection. A stock client suffices: it forwards the value as -M--compress-threads=N, so no crafted protocol is needed, and on an anonymous module no authentication happens first.

A push parses and clamps the value too but creates no workers there, since the option affects compression rather than decompression.

rsync's fork-per-connection model does NOT scope this the way it scopes a crashing child. Threads are a shared host resource: one connection can materialise hundreds of them, and concurrent connections multiply that until the host's thread or memory limits are reached, degrading or denying service to everything else on the machine rather than only to the attacker's own connection.

Fixed by clamping the requested worker count on a daemon to a small maximum (8). Local and remote-shell invocations keep the operator-requested value, since there the operator is the one asking.

Note that an administrator who tried to head this off with refuse options = compress-threads was NOT protected before 3.5.0: option refusal matched names exactly, so the short alias --zt went through. That alias-matching defect is described in the additional-hardening section.

Affected: 3.4.2 through 3.4.4 (--compress-threads was added in 3.4.2)

Fixed in: 3.5.0 (daemon requests capped at 8 workers)

Reporter: Filipe Casal of Trail of Bits in collaboration with OpenAI

Test: daemon-zstd-thread-exhaustion

Updates

2026-08-14 16:57 CEST

Metadata changes:

  • Status for package rsync: “Plausible”

2026-08-14 16:55 CEST

Metadata changes:

  • Status for package rsync: “New”