# NEWS for rsync 3.5.0 (13 Aug 2026)
## Changes in this version:
### Thanks!
This has been an extraordinary release developed over several months<br>and I'd like to thank everyone who has helped make it possible. The<br>volume of security issues we had to deal with would have been quite<br>overwhelming without the help that I've received.
I'm particularly grateful to Zen Dodd (Tao), Omar Elsayed (seks99x),<br>Will Sargeant, Paul Mackerras, Aleksa Sarai and Leonid Bugaev (buger)<br>who joined the rsync admins group helping to triage all the issues,<br>develop new tests, review PRs and helped develop the guidelines we used<br>for where to draw the line between a security issue and expected<br>behaviour (a surprisingly difficult thing to do in some cases). You've<br>all been a huge help and rsync is much better off for your assistance.
A big thank you also to Filipe Casal from Trail of Bits who worked with<br>us on the "Patch the Planet" program. Filipe provided a huge trove of<br>valuable tests and security reports.
Also a big thank you to Greg Kroah-Hartman for invaluable advice and<br>security reports and to Stuart Inglis for particularly high quality<br>bug reports and testing.
Many thanks to everyone who submitted bug reports, credits are listed<br>below against individual items.
Finally, thank you to everyone who joined in the discussion and<br>testing on the rsync-security mailing list, and to the rsync user<br>community for your patience in waiting for this release.
### SECURITY FIXES:
This release fixes 33 security issues found during a focused audit of rsync's<br>path handling and daemon protocol, a companion daemon-protocol fuzzing pass, and<br>reports from external researchers -- plus several robustness hardenings. CVE<br>IDs were assigned by VulnCheck (CNA); the precise "introduced in" version ranges<br>accompany each advisory, and many are much narrower than "everything before<br>3.5.0". Every fix ships with a regression test in the test suite that fails on<br>the unfixed tree. Many thanks to the external researchers credited below.
Link following (CWE-59/61) -- a local user who controls a path component plants<br>a symlink that a privileged rsync then follows:
- CVE-2026-53802 (HIGH): Arbitrary file read / transfer-shaping via symlinked<br>operator-supplied input files. rsync followed attacker-planted symlinks in<br>`--filter` merge files (including per-directory merges and `-C` `.cvsignore`),<br>`--files-from` / `--include-from` / `--exclude-from`, and the client<br>`--password-file` / daemon secrets file -- reading an arbitrary file as filter<br>rules, or sending a victim file's contents as the daemon authentication<br>response. Operator-supplied paths are now resolved component-by-component with<br>`openat(O_PATH|O_NOFOLLOW)`, allowing a symlink component only when it is owned<br>by uid 0 or the effective uid.
- CVE-2026-53803 (HIGH): Arbitrary file write / privilege escalation via<br>symlinked operator-supplied output paths -- `--log-file`,<br>`--write-batch`/`--read-batch`, and the daemon's motd / lock / early-input /<br>`--config` opens. A planted symlink (or parent component) could redirect the<br>write, e.g. append the log to `authorized_keys`; `--read-batch` could also feed<br>chosen bytes to the protocol parser. Same trusted-owner path walk, plus an<br>`S_ISREG` check on the `--read-batch` file.
- CVE-2026-53785 (HIGH): Under `--relative`, the receiver's implied-parent<br>creation (`make_path()`) built the parent chain with a plain `mkdir()` on the<br>full path, so a planted parent symlink placed the new directories and file<br>outside the destination tree. `make_path()` now creates each component through<br>the held-directory-fd primitive. Reported by Omar Elsayed (seks99x).
- CVE-2026-53784 (HIGH): Daemon module-root chdir escape under `use chroot =<br>no`: a plain `chdir()` followed a planted parent-component symlink, serving<br>files from outside the module. The module-root chdir now goes through the<br>secure resolver.
- CVE-2026-53793 (HIGH): Chroot `/./` inner-module escape -- a symlinked<br>parent component inside the inner module reached a sibling outside it (the<br>generator basis stat, the receiver write/finish path, the module chdir, and the<br>receiver's delta-basis open). The secure resolver is now engaged for all of<br>those paths.
- CVE-2026-53795 (HIGH): An absolute `--temp-dir` or `--link-dest` disabled<br>the receiver's rename/link confinement. `do_rename_at()`/`do_link_at()` bailed<br>to the unconfined path-based call whenever *either* path was absolute, so an<br>absolute source (the temp file, or the link-dest basis) let `finish_transfer()`'s<br>tmp->final rename -- or a hard-link create -- follow a destination parent<br>component an attacker flipped to a symlink mid-transfer, writing the file outside<br>the tree. Each side is now confined independently. Reported by Omar Elsayed<br>(seks99x).
- CVE-2026-53796 (MEDIUM): A non-daemon receiver's one-time `chdir()` into the<br>operator-named destination was not fully confined (a relative destination took a<br>plain `chdir()`), so an attacker who raced the named...