CVE-2026-41035

What it actually does

CVE-2026-41035 is a use-after-free vulnerability in rsync versions 3.0.1 through 3.4.1 when the receiver processes extended attributes via -X or --xattrs. The vulnerable receive_xattr logic trusts an attacker-controlled length value during a qsort operation, which can corrupt receiver-side memory after an object has been freed. Because rsync commonly runs over the network and can be used in client/server synchronization workflows, a malicious or compromised rsync peer with sufficient ability to participate in a transfer can potentially trigger memory corruption on the receiving side. The CVSS scope change indicates impact may cross a trust boundary, but the published severity and vector indicate low confidentiality, integrity, and availability impact rather than a reliably demonstrated full remote code execution condition.

Why it matters to the business

Organizations using rsync for backups, file replication, deployment pipelines, or administrative synchronization may face risk of disrupted sync jobs, corrupted transfer state, or limited compromise of systems receiving files with extended attributes enabled. The issue is most relevant where rsync is exposed as a service or where automated jobs pull from or receive data from less-trusted peers. Linux exposure depends on build and runtime behavior, while non-Linux platforms are described as more broadly vulnerable. EPSS is currently low and stable, the vulnerability is not listed in CISA KEV, and no public exploit maturity is reported, so this should be prioritized based on whether rsync with --xattrs is used across trust boundaries rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs a position where they can influence an rsync transfer to a vulnerable receiver, such as operating a malicious rsync server, compromising a source host used by automated pull jobs, or authenticating to an rsync module or SSH-based rsync workflow that permits them to send crafted file metadata. The attacker then prepares a transfer that includes extended attributes and malformed xattr length information. When the victim runs rsync with -X or --xattrs, the receiver parses the attacker-supplied extended attribute data. During sorting in receive_xattr, rsync uses an untrusted length value, creating a use-after-free condition in receiver memory. Successful exploitation could crash the receiver process or potentially alter limited memory state associated with the transfer; stronger outcomes such as reliable code execution would depend on platform, allocator behavior, compilation hardening, and exploit development not currently reported in the provided intelligence.

How to fix it

Upgrade rsync to a vendor-fixed release newer than the affected range, or apply the operating system or distribution security update that backports the fix. The affected upstream range is rsync 3.0.1 through 3.4.1; because no exact fixed version was provided, use the latest vendor-supported rsync package and verify that the vendor advisory explicitly addresses CVE-2026-41035. If immediate patching is not possible, reduce exposure by disabling extended attribute synchronization where it is not required, removing -X or --xattrs from scripts and scheduled jobs, restricting rsync access to trusted peers only, requiring SSH or authenticated access, limiting writable rsync modules, and preventing automated pull jobs from untrusted or weakly controlled sources. Where xattrs are business-critical, prioritize patching rather than disabling the feature.

How to confirm the fix worked

Inventory rsync installations and confirm versions with commands such as rsync --version or package-manager queries. Treat versions 3.0.1 through 3.4.1 as affected unless the distribution has backported a fix and documents that CVE-2026-41035 is patched. Review scripts, cron jobs, systemd timers, CI/CD jobs, backup tooling, and configuration management for rsync invocations containing -X or --xattrs. Validate remediation by confirming the installed package version or vendor changelog includes the fix, then rerun representative rsync jobs that require extended attributes to ensure functionality is preserved. For exposure reduction, verify that rsync daemons are not reachable from untrusted networks and that rsync modules or SSH accounts cannot be abused to provide untrusted extended attribute data to patched or unpatched receivers.

Typical attack path

1. Identify rsync endpoints, automated synchronization jobs, or backup workflows that use rsync versions 3.0.1 through 3.4.1.
2. Determine whether the receiver runs rsync with -X or --xattrs enabled.
3. Gain a position to supply rsync content or metadata to the vulnerable receiver, such as through an authenticated rsync module, SSH-based rsync account, compromised upstream source, or malicious server used by a pull job.
4. Craft file synchronization data containing extended attributes with malformed or adversarial length values.
5. Trigger the transfer so the vulnerable receiver processes the crafted xattr data in receive_xattr.
6. Cause receiver-side memory corruption, potentially resulting in process crash, transfer failure, limited data impact, or other platform-dependent behavior.

How to detect it

To assess prior exploitation, review rsync daemon logs, SSH authentication logs, syslog or journald, backup job logs, cron/systemd timer output, and endpoint crash telemetry for rsync receiver failures during transfers using extended attributes. Look for rsync processes invoked with -X or --xattrs followed by segmentation faults, abnormal exits, core dumps, allocator errors, or repeated transfer failures involving file metadata or extended attributes. Correlate suspicious failures with remote rsync peers, authenticated rsync users, SSH source addresses, recently changed upstream synchronization sources, and any transfer of unusual files with extended attributes. On Linux, review /var/log/syslog, /var/log/messages, /var/log/auth.log, journald entries, rsync daemon logs, kernel crash messages, and core dump records from systemd-coredump, apport, abrtd, or equivalent tooling. There are no provided threat actors, public exploit strings, or payload-specific network signatures, so detection should focus on behavioral evidence: vulnerable rsync versions, --xattrs usage, untrusted peer interaction, and unexplained rsync memory crashes around the time of transfers.

• rsync --xattrs
• rsync -X
• --xattrs
• receive_xattr
• rsyncd
• rsync error:
• segfault at
• rsync[
• systemd-coredump
• Process rsync
• comm="rsync"
• core dumped
• /var/log/rsyncd.log
• /var/log/syslog
• /var/log/messages
• /var/log/auth.log
• /var/lib/systemd/coredump/
• /var/crash/
• /var/spool/abrt/

What your security team should do

• Prioritize systems that run rsync as a receiver with -X or --xattrs, especially backup servers, deployment targets, file replication hosts, and non-Linux platforms.
• Patch rsync through the operating system or vendor package channel and confirm the advisory explicitly fixes CVE-2026-41035 or moves beyond the affected 3.0.1 through 3.4.1 range.
• Temporarily remove -X or --xattrs from nonessential rsync workflows until affected receivers are patched.
• Restrict rsync daemon modules and SSH-based rsync accounts to trusted sources; avoid automated pulls from untrusted or weakly governed hosts.
• Search automation repositories, cron directories, systemd units, and backup product configurations for rsync commands using extended attributes.
• Monitor for abnormal rsync crashes, failed transfers, segmentation faults, or malformed extended attribute handling after interactions with untrusted peers.
• Because EPSS is low, stable, not KEV-listed, and no exploit maturity is reported, align urgency with actual exposure rather than applying emergency internet-wide response procedures.