rsync 3.4.4 Ships to Fix Regressions From the Six-CVE 3.4.3 Security Release as Tridgell Pledges Expanded Testing
rsync 3.4.4, released June 8, repairs regressions introduced by the May 20 security update that patched six CVEs, after a debate over the maintainer's AI-assisted test-suite rewrite.
Overview
The rsync project released version 3.4.4 on June 8, 2026, a point release that exists solely to repair regressions introduced by the previous 3.4.3 security update, according to LWN.net. The new version adds no features and instead walks back several behavioral changes that broke working backup setups after 3.4.3 shipped on May 20, per the project’s NEWS file. The sequence — a security release that fixed six vulnerabilities but disrupted valid workflows, followed by a fast cleanup release — unfolded alongside a public argument over the maintainer’s use of AI tools to modernize the project’s test suite.
rsync is one of the most widely deployed file-transfer and synchronization utilities in the Unix world, underpinning backup systems, mirror infrastructure, and deployment pipelines, which is why even narrow regressions in a point release drew immediate attention.
The security release that started it
rsync 3.4.3, announced by Andrew Tridgell of the Rsync Project on May 20, 2026, fixed six separate vulnerabilities, all affecting rsync 3.4.2 and earlier, according to the oss-security announcement. The six were tracked as CVE-2026-29518, CVE-2026-43617, CVE-2026-43618, CVE-2026-43619, CVE-2026-43620, and CVE-2026-45232, per the same announcement.
The most serious of the set were reachable through normal connections rather than exotic configurations. CVE-2026-43618 was described as an integer overflow in the compressed-token decoder enabling remote memory disclosure to an authenticated daemon peer, while CVE-2026-43620 was an out-of-bounds read in the receiver’s recv_files() function enabling remote denial-of-service, the announcement states. Several of the other flaws — including CVE-2026-29518, a time-of-check-to-time-of-use symlink race allowing local privilege escalation, and CVE-2026-43619, symlink races on path-based system calls — required non-default daemon settings, specifically modules configured with use chroot = no, according to the announcement. Linuxiac summarized the set as three issues requiring non-default daemon configurations and two reachable through normal connections.
What broke
In closing those holes, 3.4.3 changed how rsync handled paths in daemon mode without chroot — and that change broke setups that had worked for years. The regressions affected backup configurations using daemon mode and incremental transfer options, according to Linuxiac. One of the most visible failures was a regression in which pulling files via the native rsync protocol returned “Invalid argument (22)” on file reads, as documented in the project’s issue tracker.
Version 3.4.4 addresses the breakage with a short list of targeted fixes. It restores correct honoring of relative alternate-basis directories such as --link-dest=../sibling on daemon receivers running use chroot = no, re-anchoring those paths at the module root, according to the NEWS file. It also lets a daemon serving the filesystem root open a module-root-absolute path for a path = / module, resolves false failed verification -- update discarded errors when resuming delta transfers with an absolute --partial-dir, and corrects a NULL dereference on the delta discard path, the NEWS file states.
Tridgell apologized for the disruption. “My apologies for the regressions in the 3.4.3 release and I hope future security updates for rsync will have less issues,” he wrote, according to LWN.net.
The AI-code debate
The security release also reignited a debate about AI-generated code in critical open-source infrastructure. Commits in the project have been attributed to “tridge and claude” since rsync 3.4.1, and a strongly worded GitHub post objecting to the practice set off the row, according to The Register. Tridgell had rewritten the project’s aging shell-script test suite in Python, designing the framework himself but using Claude — alongside OpenAI’s Codex and Google’s Gemini — to do the bulk of the conversion work, which he then manually reviewed, The Register reported.
Tridgell defended the approach as deliberate, human-reviewed engineering rather than unsupervised generation. “I did not just vibe-code “convert test suite to python”. I’m a software engineer with 40 years experience (yeah, I’m OLD!), so I did a design first and had a plan for how to validate it. I used AI tools to do the grunt work because they are good at that. I reviewed every part of it myself and ran through a huge amount of CI time getting it right,” he wrote, according to Linuxiac. He also noted that open-source maintainers now field a large volume of security reports, many of them themselves AI-generated, per Linuxiac.
The breakage that drove the cleanup release, however, traced to the security hardening rather than the AI-assisted test suite: the affected workflows centered on daemon configurations using use chroot = no, which Tridgell characterized as valid but uncommon and not covered by the existing test suite or his manual testing, according to Linuxiac.
What’s next
Tridgell has flagged a forthcoming rsync 3.5.0 release with expanded security testing, supported by a dedicated security mailing list at rsync-security@lists.samba.org and an enhanced test suite intended to catch the kind of workflow regressions that slipped through this cycle, according to LWN.net.
What We Don’t Know
The project has not published a firm release date for rsync 3.5.0, and it remains to be seen whether the expanded Python-based test suite will fully cover the daemon and incremental-transfer scenarios that the 3.4.3 changes disrupted. The longer-term question raised by the episode — how open-source maintainers should disclose and govern AI assistance in security-sensitive code — is unresolved across the broader ecosystem.