Port 873 – rsync (Remote Sync Protocol)

Port 873 is the default port for the rsync daemon (rsyncd) — rsync’s own native network protocol for synchronizing and transferring files between hosts. It’s important to keep it separate from rsync over SSH: when you run rsync -e ssh or rsync host:/path, the transfer rides an encrypted SSH session on port 22 and port 873 is never touched. Port 873 is only in play when rsync talks to a standalone rsyncd process using rsync://host/ or the host::module syntax. That daemon speaks its own cleartext protocol, exposes named modules (shares), and — critically — is often reachable with no authentication at all, which is why an open port 873 is one of the more rewarding findings on a file-serving host.

Why It’s Open

rsyncd is the classic way to publish files for many clients to pull without handing out SSH accounts: public software mirrors, OS/package repositories, backup targets, and website or CDN sync jobs. You’ll find it on Linux servers, NAS appliances (Synology, QNAP, TrueNAS all ship an rsync service), storage arrays, and the scheduled backup jobs that push data overnight. Because it’s built for unattended, many-to-one access, admins frequently stand up a module and leave it open “just for the backup network,” then the host ends up internet-facing. Where port 873 answers, its file-transfer siblings are usually one scan away — check for FTP on port 21, SFTP/SCP over SSH on port 22, and SMB on port 445.

Common Risks

• Anonymous, unauthenticated module access. The signature finding. If a module has no auth users / secrets file, anyone who can reach 873 can list modules (rsync rsync://host/) and read whatever is inside — backups, configs, source code, credentials. This is straight data exfiltration with a native client.
• World-writable modules → code execution. If read only = false, an attacker doesn’t just read files, they write them. Dropping a file into a user’s ~/.ssh/authorized_keys, a cron directory, or a web root turns file access into remote code execution.
• Weak rsyncd.conf. No authentication, use chroot = no, an over-broad path, or read-write modules all widen the blast radius. Without chroot, a crafted path or symlink can reach files outside the module’s directory.
• Cleartext protocol. The @RSYNCD handshake, any module password, and all file data cross the wire unencrypted. Anyone on the path can sniff them unless the session is tunnelled through SSH or stunnel.
• Remotely exploitable daemon bugs. rsync 3.2.7 through 3.3.0 carry a heap-overflow-plus-info-leak pair (the 2024 cluster below) that turns anonymous read access into full code execution on the server.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and list modules with nmap

nmap -sV -p 873 --script rsync-list-modules <target>

Raw banner grab with netcat

nc -nv <target> 873

The daemon greets with @RSYNCD: <version>, which pins the exact rsync build — compare it against the vulnerable 3.2.7–3.3.0 range.

List modules with the native client

rsync rsync://<target>/
rsync <target>::

List the contents of a module

rsync rsync://<target>/<module>/
rsync <target>::<module>

Pull (exfiltrate) a module anonymously

rsync -av rsync://<target>/<module> ./loot

Test whether a module is writable

echo test > proof.txt
rsync -av proof.txt rsync://<target>/<module>/

Metasploit module listing and auth check

msfconsole -q
use auxiliary/scanner/rsync/modules_list
set RHOSTS <target>
run

The modules_list scanner negotiates with the daemon, enumerates every module, and flags which ones require a password — a fast way to spot the anonymous shares. Log every open port 873, every listable module, and every read/write you confirm so the evidence lands in the pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

In January 2025, Google Cloud’s vulnerability research team disclosed a cluster of six rsync flaws (all in rsync ≤ 3.3.0, fixed in 3.4.0), coordinated as CERT/CC VU#952657. The first two chain into remote code execution against any daemon a client can read from — including anonymous public mirrors.

• CVE-2024-12084 — Heap-based buffer overflow in the rsync daemon from improper handling of an attacker-controlled checksum length (s2length): when MAX_DIGEST_LEN exceeds the fixed 16-byte SUM_LENGTH, the daemon writes out of bounds. CVSS 9.8. A client with only anonymous read access can reach it.
• CVE-2024-12085 — Information leak: manipulating the checksum length forces a comparison against uninitialized stack memory, leaking one byte at a time. CVSS 7.5. Chained with CVE-2024-12084 it defeats ASLR, turning the overflow into reliable remote code execution on the server.
• CVE-2024-12086 — A malicious rsync server can reconstruct and exfiltrate arbitrary files from a connecting client by manipulating the checksums it sends back. CVSS 6.8.
• CVE-2024-12087 — Path traversal via --inc-recursive and missing symlink verification, letting a malicious server write files outside the client’s intended destination directory. CVSS 7.5 (CWE-22).
• CVE-2024-12088 — --safe-links bypass: the client fails to check whether a symlink target itself contains another symlink, giving another path-traversal write. CVSS 7.5 (CWE-22).
• CVE-2024-12747 — Symlink race condition in rsync’s handling of symbolic links, allowing information disclosure or privilege escalation. CVSS 5.6 (CWE-362).
• CVE-2017-16548 — receive_xattr in xattrs.c (rsync 3.1.2) doesn’t check for a trailing NUL in an xattr name, causing a heap-based buffer over-read and daemon crash (CWE-125). Note: this is an out-of-bounds read / denial of service, not a path traversal — earlier versions of this page mislabeled it.
• CVE-2011-1097 — Older heap-memory-corruption bug in rsync 3.x before 3.0.8 when certain recursion/deletion/ownership options are combined, reachable from a malicious peer.

For hands-on testing, the reliable tooling is the native rsync client (list, read, write) and Metasploit’s auxiliary/scanner/rsync/modules_list; the 2024 chain’s public proof-of-concept lives in Google’s security advisory rather than a single Exploit-DB entry.

Mitigation

• Patch rsync to 3.4.0 or later. This closes the entire 2024 cluster, including the anonymous-read-to-RCE chain. Everything below assumes a patched daemon.
• Require authentication. Give every module an auth users list and a secrets file (mode 600), and never leave a module anonymous unless it’s a genuinely public, read-only mirror.
• Make modules read-only and chrooted. Set read only = yes and use chroot = yes, and point path at the narrowest directory that works so a symlink or crafted path can’t escape it.
• Restrict port 873 to trusted hosts. Firewall it to the specific backup or mirror clients that need it. There is almost never a reason to expose rsyncd to the internet.
• Prefer rsync over SSH. Running rsync -e ssh / rsync host:/path over SSH on port 22 gives you encryption and real authentication and removes the need for an open 873 entirely.
• Rescan after changes. Confirm the module list, authentication requirement, and firewall rules with rsync rsync://<target>/ and nmap -p 873 <target> once the config is locked down.

Real-World Example

On 14 January 2025, Google Cloud’s vulnerability research team published six rsync flaws and the project shipped rsync 3.4.0 the same day. The headline was the CVE-2024-12084 heap overflow paired with the CVE-2024-12085 stack-memory leak: a client needing nothing more than anonymous read access to a module — exactly what public software mirrors hand out to the world — could defeat ASLR and execute code on the rsync server. In the other direction, a malicious server could read and overwrite files on any client that connected to it, lifting SSH keys or planting a payload in ~/.bashrc. Within days, internet scans (Shadowserver) counted over 660,000 exposed rsync daemons, and CISA folded the cluster into its advisories. It’s a clean reminder that an “anonymous, read-only” rsync module is not a low-risk exposure — on an unpatched daemon it’s a direct path to the server, and there is no login step in the way.

FAQ

What is port 873 used for?

Port 873 is the default port for the native rsync daemon (rsyncd). It publishes named modules — directory shares — that clients read from or write to using the rsync://host/module or host::module syntax, typically for mirrors, backups, and file distribution. The session is unencrypted.

Is port 873 the same as rsync over SSH?

No, and this is the most common confusion. Port 873 is rsync’s own daemon protocol. When people run rsync host:/path or rsync -e ssh, the transfer goes over SSH on port 22 instead and 873 is never used. Only the standalone rsyncd service listens on 873, and unlike SSH it has no encryption and often no authentication.

Is port 873 dangerous?

It can be. rsyncd modules are frequently exposed with no authentication, so an attacker who reaches the port may be able to list modules and read — or, if a module is writable, overwrite — arbitrary files. On rsync 3.2.7–3.3.0, anonymous read access alone can be chained to remote code execution (CVE-2024-12084 / CVE-2024-12085). Treat an internet-facing port 873 as something to lock down.

What service runs on port 873?

The rsync daemon (rsyncd), rsync’s native file-synchronization protocol. It’s distinct from rsync tunnelled through SSH — the daemon on 873 speaks cleartext and is configured through rsyncd.conf.

How do I secure or close port 873?

Patch rsync to 3.4.0+, add auth users and a secrets file to every module, set read only = yes and use chroot = yes, and firewall port 873 to trusted clients. Better still, move transfers to rsync over SSH on port 22 and stop the daemon entirely, then rescan with nmap -p 873 <target> to confirm the port is closed.

TL;DR

• Service: rsync daemon (rsyncd) — rsync’s native protocol, not rsync over SSH
• Default port: 873/TCP
• Biggest risk: anonymous/unauthenticated module read and write (data exfil, or file drop → RCE), plus the 2024 RCE cluster on rsync ≤ 3.3.0
• Mitigation: patch to 3.4.0+, require auth, read-only + chroot modules, firewall to trusted hosts, or switch to rsync over SSH