Loading story…
A publicly disclosed vulnerability in rsync affects versions 3.0.1 through 3.4.1, as well as the 3.4.2 development head, due to a use-after-free bug in the receive_xattr() function. The flaw occurs because rsync uses a wire-supplied extended-attribute count as the length for qsort() instead of the number of accepted xattrs, which can pull stale entries from prior files into the current file's xattr list. A malicious rsync sender can trigger dangling pointers, read-after-free, double-free, heap corruption, information disclosure, and denial of service in the receiving process over the network.
The bug was traced to commit d724dd186, introduced during development of rsync 3.0.1pre1 in 2008 when sorting was added after namespace prefix munging for --fake-super mode. On Linux, exploitation requires --xattrs together with --fake-super or certain xattr filter configurations, while on FreeBSD, macOS, and other non-Linux platforms, any use of -X/--xattrs is vulnerable. The reported fix is to replace the qsort() count argument with temp_xattr.count, while public discussion on oss-sec also raised questions about whether and when rsync maintainers had been notified before disclosure.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
In follow-up oss-sec discussion, Salvatore Bonaccorso said the rsync use-after-free vulnerability appeared to have been assigned CVE-2026-41035 and pointed to the public CVE record. This added a formal vulnerability identifier to the previously disclosed flaw.
In follow-up discussion on oss-sec, Alan Coopersmith asked whether rsync maintainers had been notified and when that notification occurred. The exchange indicated that disclosure coordination details were still unresolved in the public thread.
Przemyslaw Frasunek disclosed a use-after-free vulnerability in rsync's receive_xattr() function, explaining that a wire-supplied xattr count was used as the qsort() length instead of the actual accepted xattr count. The report said this could cause dangling pointers, double-free, heap corruption, information disclosure, and denial of service when a malicious sender targets a receiver using extended attributes.
A vulnerable change was introduced in commit d724dd186, adding qsort() handling in receive_xattr() during development of rsync 3.0.1pre1. This change created the use-after-free condition later reported as affecting rsync 3.0.1 through 3.4.1 and the 3.4.2 development head.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
seclists.org
Open sourceseclists.org
Open sourceseclists.org
Open sourceseclists.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A vulnerability tracked as **CVE-2026-41035** affects `rsync` extended attribute handling and can be triggered when transfers use `-X` or `--xattrs`. The flaw occurs in `receive_xattr()`, where untrusted extended-attribute metadata is mishandled during sorting, causing memory corruption. Red Hat rated the issue **Important** with a **CVSS v3 score of 7.4**, warning that successful exploitation can crash the `rsync` process for denial of service and may also allow arbitrary code execution. Public debugging details tied the bug to `rsync` **3.4.1**, where `qsort()` used the wire-provided attribute count instead of the number of entries actually retained after filtering. On non-Linux, non-root receivers such as **FreeBSD**, filtered namespaces like `security.*` or `trusted.*` could leave stale or uninitialized array elements that led to a `SIGSEGV` in `rsync_xal_compare_names()` via `strcmp()` on a NULL pointer. Red Hat said exploitation requires extended attributes to be explicitly enabled, advised administrators to avoid `-X` or `--xattrs` unless necessary, and published fixes across affected Red Hat Enterprise Linux product streams.
Aug 27, 2026
A vulnerability tracked as **CVE-2026-29518** affects the `rsync` daemon and has been described as a symlink-race **time-of-check time-of-use (TOCTOU)** flaw. The issue is tied to daemon deployments configured with `use chroot = no`, a setting that removes the additional filesystem isolation normally provided by `chroot` and can increase exposure to path-handling attacks involving symbolic links. The flaw has been documented by multiple downstream vendors and trackers, including SUSE and Debian, and is reflected in upstream `rsync` release notes. Organizations running `rsync` in daemon mode should review whether `use chroot = no` is enabled, prioritize vendor patches for affected packages, and assess any services that expose `rsync` modules to untrusted clients or writable content paths.
Jun 29, 2026
Rsync 3.5.0 has been released with fixes for **33 vulnerabilities** affecting the widely used file synchronization utility, including several critical and high-severity issues in the rsync daemon, file handling, path validation, logging, proxy protocol support, and the restricted `rrsync` wrapper. The most serious flaws include client IP spoofing when `proxy protocol = true` is enabled, command-execution risks tied to `RSYNC_CONNECT_PROG` and `rsync-ssl`, arbitrary file overwrite conditions involving symlink and path-handling weaknesses, and bypasses that undermine `rrsync` restrictions. The update also addresses information disclosure, denial-of-service conditions, access-control weaknesses, and file-handling risks that can arise in privileged or chroot-adjacent deployments. Reported mitigations include restricting which hosts may use proxy protocol, avoiding unsafe privileged usage patterns, tightening file-opening behavior with protections such as `O_NOFOLLOW`, and reviewing DNS-dependent controls such as `hosts deny` logic that may be bypassed under some conditions.
Aug 14, 2026