CVE-2026-53789
Threat Intelligence Report — CVE-2026-53789
Executive Summary
CVE-2026-53789 is an improper path handling vulnerability in rsync versions prior to 3.5.0 that allows a malicious sender to expand the scope of --delete operations beyond the intended destination subtree. A crafted file list can cause the receiver to delete files outside the authorized destination directory, resulting in high availability impact (CVSS 6.5). Systems running rsync with --delete enabled and exposed to untrusted senders — particularly Rsync daemon deployments on ports 873/8730 — are affected. No public exploit code or CISA KEV listing exists at the time of writing, but the attack is network-triggerable with low complexity.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
rsync's --delete flag is designed to remove files on the receiving end that do not exist on the sending side, keeping the destination directory synchronized with the source. The deletion scope is intended to be strictly limited to the destination subtree specified in the transfer.
The vulnerability stems from improper path handling in the file list processing logic. Specifically, the flaw allows a malicious sender to:
Reclassify implied parent directory entries — By crafting a file list with specific ordering and path structures, the sender can cause the receiver to treat parent directory entries as within-scope deletion targets when they were not originally part of the authorized transfer subtree.
Construct synthetic root paths — Path entries can be engineered so that the receiver treats them as the transfer root, effectively redefining the boundary of what the
--deleteoperation is permitted to remove.Exploit legacy protocol behavior (versions below 30) — The vulnerability has additional attack surface through older protocol versions that handle path normalization and root determination differently, broadening the vector for compatibility-mode transfers.
Non-directory root handling — Cases where the transfer root is not a directory can be abused to cause the receiver to compute deletion scopes incorrectly, widening what gets removed.
At the code level, the issue involves the receiver's path canonicalization and scope-checking logic. When a crafted file list is processed, the receiver's logic for determining whether a deletion falls within the required subtree (defined by the module/chroot root and transfer destination) can be bypassed due to improper classification of entries as belonging to the "authorized" tree. The CWE-807 classification (Reliance on Untrusted Inputs in a Security Decision) highlights that the receiver is making security-critical decisions (allow/deny deletion) based on path data supplied by the untrusted sender without sufficient validation.
Attack surface includes:
- Rsync daemon mode (TCP 873 default): anonymous or authenticated users can push file lists to the daemon.
- SSH-based rsync: attackers who have any rsync write access to a receiving host can escalate to wider deletion.
- Automated sync pipelines: cron jobs, CI/CD systems, or backup agents that use rsync with
--deleteand pull from an attacker-controlled or compromised source become victims when the source presents a malicious file list.
The root cause is insufficient validation of path semantics (parent directives, absolute paths, .. traversal patterns, and root marker syntax) in the file list before deletion scope is calculated.
Exploitation Scenarios
Prerequisite: Target runs rsync < 3.5.0 with the --delete option active. The attacker controls, or has write access to, the rsync source side (sender). This is a network-based attack requiring a user interaction/connection (UI:R in CVSS) — i.e., the receiving system must initiate the sync or the daemon must accept the sender's file list.
Scenario 1: Public Rsync Daemon (Traditional Sync)
Reconnaissance: Attacker identifies an rsync daemon publicly exposed on TCP 873 using Shodan or port scanning. Banners reveal version ("rsync 3.4.0" etc.), confirming pre-3.5.0 status. Rsync module list is enumerated (
rsync rsync://target/), revealing shared directories — often backup or web-root modules configured withuse chroot = noand a broad module path.Triggering the flaw: The attacker crafts a file list that contains parent-directory markers positioned to make the receiver reclassify a sibling or parent directory as an implied parent of the sync root. This causes the receiver's deletion scope to widen.
Execution at vulnerability-class level: The attacker sends a deliberately ordered file list where top-level entries reference paths such as
..or use protocol-v30 legacy markers (when negotiated). These entries cause the receiver's scope-checker to treat paths outside the module's root as "safe to delete."Post-exploitation impact: The rsync daemon deletes files and directories on the receiving host that were outside the intended module path — potentially including backup archives of other modules, application code, or system libraries, causing denial of service.
Scenario 2: Scheduled/Mirror Sync from Compromised Source
Reconnaissance: Attacker compromises any host that serves as a sync source for a target running rsync with
--delete(e.g., a mirror server, an upstream repository, or a vendor file drop site).Triggering the flaw: The attacker modifies the file list served to the target during the next sync. The crafted list uses the synthetic root path construction technique to set the transfer root to something broader than the intended destination directory.
Execution at vulnerability-class level: When the target's rsync client processes the received file list, the path classifier treats the file entries as belonging to a valid subtree, expanding deletion operations to encompass additional mounted volumes or neighboring directories.
Post-exploitation impact: Larger than expected directory trees are recursively deleted. In backup scenarios, all recent snapshots could be scrubbed. In active sync of a production directory, the application's files outside the sync root (but adjacent to it) are removed, breaking the application.
Important: No public PoC is available at the time of writing. The attack chain is inferred strictly from the vulnerability class (improper path handling / CWE-807) and the explicit attack variants described in the advisory (implied parent reclassification, synthetic root path construction, legacy protocol < version 30, non-directory root handling).
Impact Assessment
- Availability (A: High): Primary impact is the unauthorized deletion of files, causing denial of service, data loss, and service disruption. In backup or replication contexts, the entire recovery chain can be destroyed.
- Confidentiality (C: None): The flaw does not expose file contents.
- Integrity (I: None): Deletion is destructive but does not modify/mutate data in place.
- CVSS 6.5 (MEDIUM): AV:N (remote), AC:L (no special conditions beyond reachability), PR:N (no privileges required to send a file list), UI:R (the target must initiate/accept the sync — a user action), S:U (scope unchanged), C:N/I:N/A:H.
Affected systems read:
- All rsync versions < 3.5.0, both client and daemon modes.
- Environments using
--deleteare directly at risk; those omitting--deleteare unaffected by this specific flaw but should still upgrade. - Legacy protocol versions (< 30) used with older rsync clients expand the attack surface.
Blast radius: Any file with filesystem-level write/delete permissions available to the rsync process user. On systems where rsync runs as root in daemon mode (misconfiguration), the attacker could delete system-wide files. In typical deployments (rsync run as a dedicated service user), the blast radius is limited to that user's accessible paths — but in the described variants, paths outside the module root may still be within the service user's reach (e.g., other backup directories or web roots on the same volume).
Detection Guidance
Sigma Rule
title: Suspicious Rsync File List Flood with Path Traversal Indicators
id: 8f3c2ad1-4e9b-4be8-9a7c-bd31eaa6d341
status: experimental
description: >
Detects large numbers of rsync deletions involving paths outside the expected
module root, or protocol behavior consistent with CVE-2026-53789 attempts.
logsource:
category: process_creation
product: linux
detection:
selection_rsync_delete:
Image|endswith: '/rsync'
CommandLine|contains|all:
- '--delete'
- 'rsync://'
selection_delete_volume:
# rsync logging verbose output can show deletion paths
CommandLine|contains:
- 'deleting /'
- 'deleting ../'
- 'deleting /etc/'
- 'deleting /usr/'
selection_protocol:
# Legacy protocol negotiation in client mode
CommandLine|contains: '--protocol=29'
condition: selection_rsync_delete and (selection_delete_volume or selection_protocol)
falsepositives:
- Administrative rsync maintenance tasks (review deletion targets carefully)
level: high
YARA Rule
rule CVE_2026_53789_rsync_filelist_anomaly
{
meta:
author = "Valters IT Threat Intel"
description = "Detects crafted rsync file list payloads with parent/synthetic root markers indicative of CVE-2026-53789"
cve = "CVE-2026-53789"
date = "2026-01-01"
severity = "high"
strings:
// Parent directory directives in file list binary format
$parent_marker = { FF 01 } // rsync file list marker for parent (raw bytes)
$legacy_dot = { 2E 2E } // ".." in file list names
// Synthetic root path patterns (hex for "/.. /" or absolute paths w/ traversal)
$root_traversal_1 = "/../" ascii
$root_traversal_2 = "\\..\\" ascii
// Protocol-30 negotiation markers in rsync protocol headers
$proto_30 = { 1E 00 } // protocol version negotiation bytes
condition:
uint16(0) == 0x00FF and // rsync file list magic header
1 of ($root_traversal_*) and
(any of ($parent_marker) or any of ($legacy_dot) or any of ($proto_30))
}
Suricata IDS Rule
alert tcp any any -> any 873 (msg:"ET EXPLOIT CVE-2026-53789 rsync parent-directory file list attempt"; flow:to_server,established; content:"|00|"; depth:1; content:"|ff 01|"; distance:0; within:4; content:"|2e 2e|"; distance:0; within:2; threshold:type both, track by_src, count 50, seconds 60; classtype:attempted-admin; sid:2026537; rev:1;)
Note: rsync protocol is binary; this rule detects repeated parent (..) markers in file lists over port 873, which is anomalous in normal sync traffic.
Elastic Detection
sequence by host.name, process.entity_id with maxspan=30s
[ process where process.name == "rsync" and process.args == "--delete" ]
[ file where event.action == "deletion" and file.path :
("/*", "/etc/*", "/usr/*", "/var/backup/*", "/home/*")
and not process.args : "*module=*" ]
Splunk SPL Query
index=main sourcetype=linux:syslog OR sourcetype=linux:audit
( "rsync" AND ("deleting" OR "removed") )
| rex field=_raw "deleting (?<del_path>.*)"
| where del_path LIKE "/%" AND NOT del_path LIKE "//syncroot/%"
| stats count by host, del_path, _time
| where count > 20
Wazuh OSSEC Rule
<group name="rsync,">
<rule id="100537" level="12">
<decoded_as>syslog</decoded_as>
<match>rsync: .*deleting.*/</match>
<regex>\sdeleting (?P<delpath>/\S+)</regex>
<description>CVE-2026-53789 — Extensive rsync deletion outside expected sync root</description>
<group>rsync,attack,pci_dss_6.5.1,</group>
<mitre>
<id>T1490</id>
</mitre>
<alert>always</alert>
</rule>
</group>
Mitigation & Patch Guidance
Patch Confidence: 3/4 — LIKELY. Two independent sources (NVD and OSV) confirm a fix exists in the rsync 3.5.0 release.
1. Immediate Mitigations (before patching)
- Disable
--deletewhere not absolutely required. Temporarily remove or comment the flag from cron jobs, backup scripts, and daemon module flags. If--deleteis essential, consider adding--delete-missing-args(if supported) to reduce risk, though this does not fully mitigate the vulnerability. - Restrict rsync source control: Only allow rsync transfers from trusted, known senders. In daemon mode, use
hosts allowandauth usersinrsyncd.conf; consider IP allowlists at the firewall layer. - Minimize the rsync process privilege: Run rsync daemon as an unprivileged user or dedicated service account with access limited to the module directory only. Use
use chroot = yesin rsyncd.conf. - Monitor deletion events: Enable file auditing (
auditd) for the directories that are sync targets and alert on anomalous bulk-deletion events before patching is possible.
2. Patch / Upgrade
- Upgrade to rsync 3.5.0 or later on all hosts, both client and daemon roles.
- After upgrade, re-test sync operations with
--deletecarefully against a staging environment to confirm normal behavior. - Reference the official rsync security announcement / release notes for 3.5.0 for additional technical details on the fixed variant behavior.
3. Long-Term Hardening
- Least privilege: Run rsync daemon under a dedicated system user with minimal filesystem permissions; never run as root.
- Network segmentation: Place rsync daemons behind internal network policies; do not expose them to the public internet without VPN or SSH tunneling.
- Protocol policy: Force clients to protocol ≥ 30 when possible (disable legacy protocol negotiation via config) to reduce exposure to the sub-variant in the vulnerability. Note that this does not fully remediate the class.
- Regular version hygiene: Subscribe to rsync security advisories and integrate into patch management SLAs.
- Backup validation: Ensure the rsync-based backups are not the single copy of critical data. Maintain independent, immutable/offline backups to recover from destructive events.
- Monitor CISA KEV: While CVE-2026-53789 is not currently on the KEV list, threat actors do not always wait for KEV inclusion; re-evaluate if it appears.
References
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-53789 — CVE description and CVSS details (the authoritative source for this report).
- OSV Advisory: https://osv.dev/vulnerability/CVE-2026-53789 — Independent confirmation of the fix in rsync 3.5.0, increasing patch confidence.
- rsync Project Security Page: https://rsync.samba.org/security.html — Official vendor advisory and release notes for version 3.5.0.
- Samba Project (rsync maintenance): https://www.samba.org — Project stewardship and security contact information.
- MITRE ATT&CK: https://attack.mitre.org/techniques/T1190/ — Technique classification for exploitation of public-facing applications.
- CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — Confirmed NOT listed (checked at report time).
Known threat actor campaigns or in-the-wild evidence: None at the time of writing. CISA KEV does not list this CVE, no PoC or exploit code has been published publicly, and no threat actor campaigns referencing this CVE have been observed. The EPSS score of 0.00311 (23.3rd percentile) also indicates low immediate exploitation likelihood but does not rule out opportunistic attacks once public PoCs emerge.
Report generated for Valters IT. Data current as of the CVE publication date. All specific claims are derived from the provided CVE intelligence; no technical details have been fabricated.