CVE-2026-70457 is an out-of-bounds write in rsync 3.2.3 before 3.5.0, rated medium (CVSS 6.5) in the record and high by VulnCheck. The bug is in the function that parses size arguments. The fix is rsync 3.5.0, which the project calls a major security release.
What's affected
rsync versions from 3.2.3 before 3.5.0. VulnCheck states the range as 3.2.3 through 3.4.4. The fix is in rsync 3.5.0, released on 13 August 2026, which the project's release page describes as a major security release with details in its NEWS file.
The weakness is CWE-131 (incorrect calculation of buffer size) and CWE-787 (out-of-bounds write). In parse_size_arg(), the return value of snprintf() is used as an index into an array in the .bss segment without a bounds check. When snprintf truncates the text, its return value is the length it would have written, which can exceed the array, so the write lands outside the array and corrupts .bss memory.
Severity differs by source. The record scores it 6.5 medium with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H. VulnCheck lists 8.3, high, using a CVSS 4.0 vector. The scores come from different scoring versions, so treat both as valid inputs to your own prioritization.
How to check if you're exposed
Check the version on every system that runs rsync, as a client or a daemon:
rsync --version | head -1
Anything from 3.2.3 up to and including 3.4.4 is in range. Distribution packages often backport fixes without changing the upstream version number, so also check your distribution's security tracker for the CVE and the package version that fixes it.
rsync also hides inside other things: backup tools, deployment scripts, container images and appliance firmware. Scan your container images for the rsync package to find copies you did not install on purpose. free in-browser dependency scan covers language dependencies in your manifests.
What to do now
- Run the rsync version check above on hosts and in container images to find versions 3.2.3 through 3.4.4.
- Upgrade to rsync 3.5.0 or later, or to the distribution package your vendor marks as fixed.
- Check the distribution security tracker, since backported fixes keep older version numbers.
- Review the rsync NEWS file for 3.5.0 for other security changes that may affect your configuration.
- Where an rsync daemon is exposed, limit it to networks that need it.
Why it matters
The bug is a classic C pitfall. snprintf returns how many characters it wanted to write, not how many it wrote. Using that number as an index assumes the text always fit. When it does not, the index points past the end of the array.
The record's attack complexity is high and its integrity impact is low, which is why the base score stays in the medium band. The availability impact is high, since memory corruption can crash the process. rsync runs backups and deployments, so a crashed or corrupted transfer can matter more than the number suggests.
Quick check
Why do two sources give different severity?
The record uses CVSS 3.1 and scores 6.5 medium. VulnCheck publishes 8.3 high with a CVSS 4.0 vector. They are different scoring systems, so the numbers are not directly comparable.
Sources
- rsync v3.5.0 release
- VulnCheck advisory
- rsync GitHub security advisory GHSA-pg7g-xqmr-xpfh (not retrievable when I checked)
Last reviewed: 18 October 2026.
