Loading story…
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.
See real exploitation activity before you spend the cycle.
12 events from the most recent confirmed update back to the earliest known activity.
The rsync project released fixes for 33 security issues identified through path-handling and daemon-protocol audits, fuzzing, and external reports. FreeBSD's net/rsync advisory directed affected systems to update, covering CVEs including CVE-2026-53783 through CVE-2026-53803 and CVE-2026-70452 through CVE-2026-70464.
Red Hat issued RHSA-2026:20604 for RHEL 9.4 Extended Update Support and related lifecycle channels, providing rsync-3.2.3-19.el9_4.3. The update remediates CVE-2026-41035 and CVE-2025-10158 across x86_64, aarch64, ppc64le, and s390x.
Red Hat issued RHSA-2026:20603 for RHEL 9.6 servicing channels, providing rsync-3.2.5-3.el9_6.1 to remediate CVE-2026-41035 along with CVE-2024-12086 and CVE-2025-10158. Fixed packages were supplied for supported x86_64, aarch64, ppc64le, and s390x offerings.
Red Hat issued RHSA-2026:20602 for RHEL 9.2 Update Services for SAP Solutions and associated lifecycle channels, providing rsync 3.2.3-19.el9_2.3. The update remediates CVE-2026-41035 and CVE-2025-10158 for x86_64, aarch64, ppc64le, and s390x systems.
Red Hat listed Red Hat Enterprise Linux 10 as fixed for CVE-2026-41035 via advisory RHSA-2026:19152. This was one of the product-stream remediations published for the rsync vulnerability.
Red Hat listed Red Hat Enterprise Linux 8 as fixed for CVE-2026-41035 via advisory RHSA-2026:17481. The advisory identifies the issue as an Important-severity rsync flaw in extended attribute handling.
Red Hat listed Red Hat Enterprise Linux 9 as fixed for CVE-2026-41035 via advisory RHSA-2026:19368. The Bugzilla notice identifies the issue as an rsync receive_xattr use-after-free vulnerability triggered when xattrs are enabled.
The Red Hat advisory states that CVE-2026-41035 was made public as an rsync vulnerability involving extended attribute handling. The flaw can be triggered when rsync is run with -X or --xattrs and may lead to denial of service or possible code execution.
Red Hat Bug 2415637 reported CVE-2025-10158, an rsync out-of-bounds heap-buffer read caused by negative array-index access. A malicious receiving rsync client with read access to a remote module can trigger the issue.
On June 11, 2026, Red Hat listed fixes for CVE-2026-41035 across several product streams, including RHEL 6 ELS Extension, RHEL 7 ELS, RHEL 8.4 AMCU and EUS Long-Life Add-On, RHEL 8.6 AMCU and EUS Long-Life Add-On, and RHEL 8.8 TUS. These advisories expanded remediation coverage for the rsync flaw.
Red Hat listed Red Hat Enterprise Linux 10.0 Extended Update Support as fixed for CVE-2026-41035 via RHSA-2026:20696. The fix addressed the rsync extended-attribute vulnerability in that product stream.
A GitHub issue documented that rsync 3.4.1 can crash with SIGSEGV in receive_xattr() because qsort() uses the wire-provided xattr count instead of the filtered entry count. The report included a reproducible FreeBSD/Linux scenario and proposed changing the qsort() call to use temp_xattr.count.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See real exploitation activity behind this advisory so you can triage it against everything else in the queue.
17 references tracked. Mallory keeps watching after this page renders.
tenable.com
Open sourceaccess.redhat.com
Open sourceaccess.redhat.com
Open sourceaccess.redhat.com
Open sourceaccess.redhat.com
Open sourcegithub.com
Open sourcecve.org
Open sourcebugzilla.redhat.com
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 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.
Jun 29, 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
dCERT issued two advisories for **Rsync** covering separate vulnerabilities that could expose organizations using the file synchronization tool to attack. One advisory describes an **unspecified attack** path in Rsync, indicating a flaw that could be exploited without public technical detail in the notice, while a second advisory warns that another vulnerability could allow attackers to **bypass security measures**. The paired notices indicate multiple security issues affecting Rsync and raise concern for environments that rely on it for file transfer, backup, or synchronization workflows. Although the advisories provide limited public detail, the combination of an attack-enabling flaw and a security-control bypass suggests defenders should review affected Rsync deployments, monitor for vendor guidance, and prioritize remediation once patches or mitigation steps are confirmed.
Jun 29, 2026