Rsync’s security update fixed 6 flaws, and may have quietly broken some backups, sparking an AI backlash

Rsync just shipped a security update meant to close six known vulnerabilities. Instead, some system administrators say the new release is doing the one thing rsync can’t afford to do: making incremental backups behave unpredictably.

The version, rsync 3.4.3, landed May 20 as a patch-heavy release for one of the most widely used file-sync tools in the Linux and Unix world. But reports of regressions, especially in daemon mode and incremental transfer workflows, have pushed some teams to freeze upgrades or roll back, even as they weigh the risk of leaving security fixes on the table.

Then came the accelerant: a visible trail of recent code changes credited to “tridge and claude”, a reference to rsync co-creator Andrew Tridgell and Claude, the AI assistant from Anthropic. For admins who treat rsync like plumbing, the idea of AI-assisted commits in critical infrastructure code has turned a routine update into a trust fight.

A security release with six CVEs, and fast-moving regression reports

Rsync 3.4.3 was billed as a security update, addressing six CVEs affecting rsync 3.4.2 and earlier. In many organizations, that’s the kind of release that gets pushed quickly, especially if rsync is exposed via its daemon or used in scheduled sync jobs.

But almost immediately after the May 20 release, users began reporting behavior changes they say broke expected results, including incremental transfers that no longer produce the same output after upgrading. In backup land, “mostly works” is the same as “doesn’t work,” because the failure can stay hidden until the day you need a restore.

One technical detail showing up in discussions: changes tied to daemon configurations usingchroot = no. That setting exists in real-world deployments, and it’s now at the center of some of the post-3.4.3 problem reports. The complaint isn’t just that bugs exist, it’s that a security-focused release appears to have shifted behavior admins believed was stable.

The practical response has been blunt. Some teams say they’re reverting to older versions, with “go back to 3.4.1” becoming a common refrain, because predictability matters more than novelty when your restore plan depends on it.

“tridge and claude”: why AI-assisted commits hit a nerve

The regressions alone would have been enough to irritate users. What changed the tone is the paper trail: since rsync 3.4.1, numerous commits are signed “tridge and claude,” explicitly crediting Tridgell and Anthropic’s Claude.

Even if no one can point to a single bug and say “the AI did this,” the optics are powerful. Rsync is the kind of tool many admins consider “done”, not because it’s perfect, but because its value comes from repeatability. When a core infrastructure utility starts changing quickly, and the changelog hints at AI involvement, some users immediately worry about code that wasn’t fully understood, reviewed, or tested against messy real-world setups.

There’s also a broader feedback loop fueling the anger. Maintainers across open-source projects have complained about a surge of security reports generated with AI, lots of volume, uneven quality, and more time spent triaging noise. In that environment, using AI to move faster can look tempting. To users, it can look like the project is trading careful review for speed.

Plenty of critics aren’t arguing “no AI, ever.” They’re arguing for process: rigorous review, real testing, and validation that covers the edge cases people actually run in production, not just a clean compile and a couple unit tests.

The maintainer weighs rsync 3.4.4 vs. 3.5, while admins hit pause

Tridgell has responded publicly, acknowledging the regression concerns and saying he’s working on fixes. He’s floated two paths: a 3.4.4 release to address at least some of the problems, or pushing ahead to a larger 3.5 release with more extensive security-related changes.

That may be reasonable from a maintainer’s perspective, but it leaves operators stuck in the middle. Sysadmins don’t get to wait for a roadmap to settle. They’ve got nightly jobs, scheduled syncs, rotation policies, and maintenance windows. So the immediate playbook is familiar: freeze upgrades, pin packages, or roll back if the update already landed.

Community chatter also highlights how much Linux distribution policies can buffer, or accelerate, pain. Some users pointed out they’re still on much older rsync builds in “stability-first” environments, while others testing 3.4.3 described a quick “ruh-roh” moment. The same upstream change can be a non-event for one shop and a fire drill for another.

The catch is that 3.4.3 is also a security release. Rolling back can mean giving up fixes for real vulnerabilities, even if some require non-default configurations to be exploitable. Admins are left choosing between two risks: theoretical exposure versus a concrete chance your backups won’t restore.

Why a small rsync regression can become a big production bill

Rsync isn’t just a command people run manually. It’s embedded in backup scripts, cross-site replication, software deployments, repository mirrors, and migration workflows. When incremental behavior or daemon mode changes, the blast radius can be huge, and easy to miss at first because jobs may still “complete” while producing subtly wrong results.

A classic failure mode: hourly incrementals plus a full backup on the weekend. If incrementals start skipping a corner case or interpreting an option differently, you can rack up days of “green” backups that are useless when you actually need them. That’s why admins react so strongly: the most dangerous backup failure is the silent one.

Even outside backups, regressions can trigger heavier transfers, longer job times, blown maintenance windows, and network spikes, the kind of cascading operational costs that don’t show up in a changelog but hit hard in production.

And once trust cracks, the overhead climbs. Teams add extra verification, more restore tests, more monitoring, more guardrails. That’s good hygiene, and it costs time and money. For some admins, the AI angle has become a symbol of unwanted variability in a tool they rely on precisely because it used to be boring.

Open source, AI, and the real issue: how critical code gets changed

Strip away the shouting, and the core question isn’t whether AI is “allowed.” It’s what standards should apply when you touch infrastructure code that thousands of organizations depend on. Maintainers say they’re drowning in security reports, some of them AI-generated, and that triage burden can distort priorities and timelines.

But automation can also move risk around. If AI-assisted contributions arrive faster than humans can thoroughly review and test them, regressions become more likely. The “Claude” signature just makes that tension visible. The underlying problem, too many changes, not enough validation, can happen with or without AI.

Some users are already floating alternatives such asopenrsync. That doesn’t mean a mass migration is imminent, but the fact that people are talking about switching is a warning sign. Infrastructure tools run on collective confidence, and once that confidence wobbles, adoption can erode even after bugs get fixed.

The bigger takeaway is uncomfortable: the internet leans on a small number of heavily used open-source projects maintained by a relatively small pool of people. As security pressure rises and AI increases both the volume of reports and the speed of code changes, incidents like this may become less of an exception, unless the process around testing, review, and release discipline gets stronger.