CVE-2026-53789 is a medium severity (CVSS 6.5) flaw in rsync. A malicious sender can send a crafted file list that widens the scope of delete operations, so the receiver removes files outside the intended destination. Upgrade to rsync 3.5.0. The steps below show how to check your version and what to change.
What's affected
- rsync 3.4.4 and earlier. Fixed in 3.5.0.
The record says versions before 3.5.0. The GitHub advisory says 3.4.4 and earlier are affected and 3.5.0 is patched. These agree. The advisory rates it Moderate, 6.5 (CVSS 3.x), matching the record's Medium.
The advisory describes several variants with the same root cause: a peer reclassifying a transfer root or implied parent entry so that deletion reaches further than the client requested. It covers an older protocol path below version 30 and a case where forced replacement of a directory can wipe the destination. On a writable daemon module, one variant bypasses the refuse options setting for delete.
How to check if you're exposed
Print the version on every host that pulls from remote sources:
rsync --version | head -1
Then list your scripts and cron jobs that pull from a remote host or daemon with delete options enabled:
grep -rn "rsync" /etc/cron* /usr/local/bin 2>/dev/null | grep -i delete
The risky pattern is a client that receives from a sender you do not fully control while delete options or forced replacement are on. Pushing to a remote host is a different direction and is not the case the advisory describes.
What to do now
- Upgrade to rsync 3.5.0 or install a distribution package that lists this CVE as fixed.
- Until then, avoid pulling from untrusted or shared daemons with delete options enabled.
- Pull into a dedicated directory that holds only the data being synced, so a widened delete has nothing else to remove.
- Keep recent backups and snapshots of destination directories that sync from remote sources.
- Rebuild images and appliances that embed rsync.
Why it matters
The record lists CWE-807, reliance on untrusted inputs in a security decision. Here the receiver trusts flags and entries in the sender's file list when deciding which directories count as content that can be cleaned. A dishonest sender can change that classification.
The fix is on the receiving side. Parent directories that the client only named as a path are downgraded so deletion cannot run on them regardless of what the sender claims, and a transfer root that arrives as a non-directory is rejected. The lesson is that anything coming from a peer should not widen what the local side is allowed to destroy. The record does not mark this CVE as known exploited.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I at risk if I only push files out?
The advisory describes a malicious sender affecting the receiver. Pulling from an untrusted source with delete options is the risky case.
Does the refuse options setting protect a daemon module?
The advisory says one variant bypasses refuse options for delete, because the deletion happens through forced replacement. Upgrade rather than relying on that setting.
Sources
Last reviewed: 18 October 2026.
