CVE-2025-10158 rsync Receiver Out-of-Bounds Read Fixed Upstream

A newly disclosed vulnerability in the widely used file-synchronization utility rsync — tracked as CVE-2025-10158 — allows a malicious rsync receiver to induce an out-of-bounds read of a heap buffer by exploiting a negative array index; the issue was fixed upstream in a small commit but remains an important patch-and-mitigation item for any organization running rsync daemons or allowing untrusted access to rsync modules.

Background / Overview​

Rsync is a ubiquitous tool for efficient file synchronization and backup across networks. It operates in several modes: as a client invoking a remote shell (typically SSH), and as a daemon exposing named modules that remote clients may read from or write to. The exposed-daemon mode (rsyncd) is common for public mirrors, backup endpoints, and appliances. The newly assigned CVE identifies a logic error in rsync’s sender-side code that can be triggered by a malicious receiver during a transfer session. Multiple vulnerability databases confirm the record: the NVD has a published entry for CVE-2025-10158 and community aggregators list the same technical summary, while the upstream Rsync project accepted and committed a one-line defensive change to the sender code to prevent invalid array access. This article explains the technical root cause, assesses exploitability and operational risk, explains remediation steps and mitigations, and supplies detection and hardening guidance for administrators responsible for rsync servers, NAS appliances, backup infrastructure, and CI/CD endpoints that rely on rsync transfers.

---

What the vulnerability is (plain English)​

• The bug is an out-of-bounds read triggered by using a negative integer as an array index when the sender attempts to look up a file entry. This lets a malicious receiver influence an index and cause the sender to reference an invalid slot in an array on the heap.
• The attacker model requires the malicious party to act as the receiver in an rsync session and to have at least read access to the remote rsync module they are interacting with; it is not a blind remote network-only exploit that requires no access to the module.

The upstream rsync commit message credits the discovery to a security researcher at Rapid7 (Calum Hutton) and explicitly notes that while the bug is “real,” analysis shows it cannot be leveraged into an exploit for remote code execution — though information disclosure or protocol errors are possible. The fix is surgical: a defensive check to avoid indexing the files array with a negative parent index.

---

Technical anatomy: where the bug lived and why​

The vulnerable code path​

At a high level, rsync maintains per-transfer file lists and indexes into arrays of file descriptors when sending file metadata or contents. In the sender code path, an index variable (parent_ndx in the upstream patch) was used as an array subscript without a prior check that the value was non‑negative. If the receiver can influence that index to be negative, the sender ends up dereferencing an out-of-range slot in a heap-based files array, producing an out-of-bounds read. The upstream patch inserts an explicit check for a negative parent index and aborts the transfer with a protocol error if found.

Why negative indexing matters in C​

C does not protect array accesses; using a signed integer that becomes negative as an index leads to reading memory before the array base. On modern systems, such reads usually produce either corrupted data (information leakage) or a crash if the memory read touches an unmapped area. While out-of-bounds writes are typically the highest-risk defects (since they enable memory corruption and potential code execution), reads can still disclose memory contents useful for further attacks, or cause denial-of-service via crashes. The rsync maintainers’ analysis and the commit commentary indicate the path cannot be straightforwardly escalated to remote code execution, but the bug remains worth fixing because it is a memory-safety error in privileged network-facing code.

---

Exploitability, impact, and scoring​

Attack vector and prerequisites​

• Attack vector: Network, during an rsync transfer where the attacker is the receiver and the target runs an rsync daemon or accepts a protocol-mode transfer.
• Privileges required: Low — read access to the remote rsync module (no local shell on the host required), as reported by public trackers.

Likely outcomes​

• Information disclosure (possible): The out-of-bounds read can return heap memory contents to the attacker in certain contexts, depending on how rsync handles and returns the read data.
• Denial of service (possible): If the read touches unmapped memory or triggers sanitizer/guard conditions, the sender process could crash, interrupting transfers and potentially affecting service availability.
• Remote code execution (unlikely/unverified): Upstream analysis indicates this specific bug cannot be leveraged into a reliable RCE in its current form; public trackers and the commit note treat RCE claims as unproven. Administrators should treat RCE as unlikely unless additional enabling flaws are present.

Severity and scoring​

• Several trackers aggregate a CVSS v3.1 base score around 4.3 (Medium) with vector AV:N/AC:L/PR:L/UI:N and an impact profile that emphasizes low integrity impact and no confidentiality/availability impact in the canonical scoring — a reflection of the read-only nature of the bug and the mitigation that exploitation needs targeted conditions. These values are reproduced across OSV and community feeds.

---

What was changed upstream (the fix)​

The upstream rsync maintainer applied a minimal, low-risk patch to the sender source file that checks whether parent_ndx is negative before it is used to index the files[] array. If the parent index is invalid (negative), the code now cleans up and aborts the transfer with a protocol error rather than dereferencing an out-of-range array element. The one-commit fix is intentionally small and designed to preserve correct behavior for valid inputs. This is a typical defensive-coding approach: convert an implicit trust of protocol-derived indices into an explicit validation step and fail fast on malformed inputs.

---

Who should care — affected deployments and the long tail​

• Public or internal rsync daemons that allow unauthenticated or lightly authenticated read access to modules (common for public mirrors and some backup endpoints).
• Backup servers and NAS appliances that expose rsync services to networked clients.
• CI/CD runners, build agents, and virtualization hosts that use rsync for image or artifact distribution and may accept rsync transfers from untrusted tenants.
• Vendors and integrators who statically link rsync into appliances or SDKs — these long-tail devices often lag on updates and may remain vulnerable until a firmware or appliance update is issued.

Even though the bug requires read access to a module, environments that expose modules publically or to semi-trusted networks effectively widen the attacker surface. Hardening access controls and patching remain high-priority.

---

Immediate mitigation and recommended remediation steps​

The fastest, most reliable remediation is to install vendor-provided rsync packages that include the upstream fix, or build and deploy a patched rsync binary that contains the corrective commit.
Practical remediation checklist:

• Inventory
• Enumerate hosts running rsync in daemon mode. Look for running services (systemd units like rsyncd.service) and check configuration files (commonly /etc/rsyncd.conf).
• Identify appliances and vendor images that may include a bundled or static rsync binary.
• Update (recommended)
• Apply vendor or distribution updates that include the upstream fix. Most major distributions and downstream trackers have mapped the CVE; prioritize hosts exposed to untrusted networks.

Example (Debian/Ubuntu):

• sudo apt update
• sudo apt install --only-upgrade rsync
• sudo systemctl restart rsync.service

Example (RHEL/SUSE/openSUSE):

• zypper refresh && zypper update rsync
• sudo systemctl restart rsync.service

Note: exact package names and versions vary by distribution; consult your vendor security tracker or package changelog to confirm the fixed package version before mass rollout.

• Compensating controls (if patching will be delayed)
• Restrict network access to rsync services: apply firewall rules (ipsets, host-based firewalls) to allow only trusted management subnets.
• Enforce authentication: disable anonymous read modules or require strong credentials for module access.
• Prefer rsync-over-SSH for critical transfers: when possible, use rsync via SSH tunnels (rsync -e ssh), which avoids the rsyncd protocol surface entirely.
• Rate-limit and monitor module access with connection throttles or reverse-proxies where applicable.
• Appliance/vendor devices
• Contact vendors for firmware or appliance updates if the device bundles rsync. Track vendor security advisories and schedule maintenance windows to apply updates.
• Verify
• Confirm the fix by checking rsync package changelogs or by validating the local rsync binary against the upstream commit (for source-built deployments). Upstream commit hash: the authoritative fix was merged in the Rsync project repository in a small commit that adds the parent-index check.

---

Detection, logging, and hunting guidance​

• Audit rsync server logs for unexpected “protocol” errors or unusual session behavior. If attackers are experimenting with crafted inputs to trigger the bug, you may see repeated failed sessions or abnormal termination codes.
• Add network telemetry rules to flag unusual or frequent module listing or file-list requests from single IPs, particularly from external networks.
• Vulnerability scanning: run authenticated or network-based checks against rsync endpoints using up-to-date scanner signatures; many security scanners and OSV/NVD-based feeds have already added detection for CVE-2025-10158.
• For deeper forensics, collect packet captures of rsync sessions suspected of probing or abuse and look at the file-list/metadata exchange sequences; correlate with host-side rsyncd logs and process crash traces if any crashes occurred.

---

Risk assessment and recommended prioritization​

• Prioritize patching on hosts that:
• Expose rsync modules to untrusted or semi-trusted networks;
• Serve as backup targets for many clients (multi-tenant backup servers);
• Are appliances or devices with slow update cycles (NAS boxes, embedded firmware).
• Medium priority for internal-only rsync endpoints that require authentication and are not reachable from the internet; however, defend-in-depth still applies.
• Low priority for endpoints where rsync is only run client-side over SSH against well-managed servers that already validate client keys and restrict access.

Distributors and vendors have begun classifying the issue as moderate; the canonical CVSS on several trackers reproduces a base score around 4.3 (Medium), reflecting the limited but real information-disclosure risk combined with low exploitation complexity in the presences of required preconditions.

---

Why the upstream fix and disclosure approach are reasonable​

• The upstream commit is small and surgical: it validates a protocol state variable and aborts on malformed input. This minimizes regression risk while eliminating the memory-safety hole.
• The maintainer’s note explicitly acknowledges the report and thanks the researcher, and states that the issue cannot be exploited for code execution in normal circumstances — a frank, conservative stance that helps administrators prioritize without underestimating the file-safety risk.

---

Practical hardening checklist (quick reference)​

• Patch rsync to a version containing the fix; verify package changelogs.
• Restrict network reachability to rsyncd (use firewall rules, VLAN segmentation).
• Disable anonymous read modules; require authentication and least privilege.
• Where possible, migrate critical transfers to rsync-over-SSH or SFTP.
• Monitor rsync logs and network telemetry for anomalous listing/get patterns.
• Track vendor advisories for appliances that might include a static rsync binary.

---

Final analysis: strengths and risks​

• Strengths:
• The defect is localized and easy to fix; upstream applied a conservative, minimal change that preserves behavior for valid transfers.
• The attacker model requires specific conditions (receiver role + module read access), which reduces the remote, unauthenticated risk for many default configurations.
• Public trackers and upstream commentary are consistent that the issue is a memory-safety bug but not a direct RCE path.
• Risks and residual concerns:
• Any memory-safety defect in a network-facing daemon is valuable to attackers; even if immediate RCE is improbable, the bug could be combined with other weaknesses or used for reconnaissance (memory leaks).
• Long-tail devices and appliances that embed older rsync binaries may remain vulnerable for months if vendors do not promptly ship updates.
• Administrators who expose rsync modules to broad networks without strict access control effectively widen the window of exploitation risk.

Where claims about exploitability are unverified (for example, claims that this defect enables remote code execution), treat them cautiously: rely on authoritative technical notes from upstream and NVD/OSV assessments rather than sensational reporting. The upstream repository maintainers who reviewed and committed the fix explicitly note the low exploitability, and multiple vulnerability trackers mirror that assessment.

---

Conclusion​

CVE-2025-10158 is an important but contained memory-safety issue in rsync: an out-of-bounds read through a negative index in the sender path that a malicious receiver can trigger when it has read access to a remote rsync module. The upstream project fixed the problem with a minimal defensive check, and distributors and downstream trackers have begun mapping the fix into packages. Administrators should treat this as a patch-now item for any rsync servers reachable from untrusted networks and as a mitigate-and-schedule item for appliances and embedded systems that rely on vendor updates. Practical mitigations — restricting rsync network exposure, requiring authentication, and migrating sensitive transfers to rsync-over-SSH — reduce risk while you update.

---

If an organization needs to validate whether a local binary is patched, inspect the rsync package changelog supplied by your distribution or compare your sender.c against the upstream commit that inserted the parent-index check; for packaged environments, rely on your distribution’s security advisory to map CVE → package version before rolling updates into production.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center