Port 873 (rsync): Risks and How to Secure It

Written by Ruben Selby, Founder and Lead Security Consultant, Wolfcore. Last reviewed 10 November 2026.

Part of the Wolfcore Resources library: Ports, protocols and services.

In one sentence: Port 873 is the door a file-copying and backup service called rsync uses when it runs as a network server, and if that door is open to the internet, strangers may be able to list, read or even change your files.

What runs on port 873 (rsync)

Rsync is a tool that copies files between machines and only sends the parts that changed. Many backup products use it underneath. CERT/CC notes that backup programs such as Rclone, DeltaCopy and ChronoSync use rsync as their backend, and that rsync in daemon mode is widely used on public mirrors.

There are two ways rsync talks to another machine. The usual way runs over a remote shell, normally SSH, which authenticates the other side and encrypts the traffic. The second way is a direct connection to an rsync daemon. The rsync manual says connections to an rsync daemon typically use TCP port 873. The same manual says a direct daemon connection is not encrypted. Port 873 is therefore the “daemon” door, not the SSH one.

Why attackers look for it

Internet-wide scanners and device search engines record which addresses answer on which ports, so an open 873 can be found without anyone targeting you by name. An attacker does not need to know your company. They filter by port, connect, and ask the daemon which “modules” (named shared folders) it offers. A daemon set up quickly “just for the backup job” is often forgotten.

How it gets attacked

No password on a module. Modules can be configured for anonymous access. That is intended for public mirrors and dangerous for anything else.
No encryption. Anything sent to a daemon travels without the protection SSH would add.
Old versions. CERT/CC vulnerability note VU#952657 covers six flaws in rsync 3.3.0 and below, including CVE-2024-12084 (a heap buffer overflow in the daemon) and CVE-2024-12085 (an information leak). CERT/CC says that combined, these let a client run code on a machine running an rsync server, needing only anonymous read access such as a public mirror offers.
Malicious servers. The same note says an attacker-controlled rsync server can read or write files on connecting clients, for example by overwriting shell start-up files. Your backup clients matter too.

Who it affects and how badly

Sole trader to 10 staff: a NAS or backup box with rsync switched on and a port forward. Worst case: backups copied by a stranger, or replaced.
10 to 50 staff (accountancy, legal, recruitment): a server exposing a client document module. Worst case: client files taken, which can trigger a personal data breach report to the ICO.
Regulated businesses (fintech, insurance, care providers): backups hold regulated data. Worst case: reportable breach, regulator questions and lost clients.

What we check on a test

Whether 873 answers from the internet, found from your own address list and a port scan we are authorised to run.
Whether the daemon lists its modules without a login.
Whether modules are read-only and limited by address.
The rsync version against the CVEs in VU#952657.
Whether backup clients connect over SSH instead of the daemon.

The UK angle

The NCSC’s Cyber Essentials requirements say firewalls must block unauthenticated inbound connections by default, and that inbound rules must be approved and documented with the business need. Software must be updated within 14 days of release where the update fixes critical or high-risk vulnerabilities. An open, unpatched port 873 fails both ideas.

Diagram

Worked example (illustration, not a real case)

A 12-person accountancy firm lets a supplier set up a nightly backup to a small server. The supplier forwards port 873 and leaves the module open. Nobody records the rule. A stranger finds the port, lists the module and downloads client working papers. The firm must assess whether to tell the ICO and its clients. The fix would have cost an hour: SSH keys, daemon on localhost, port 873 closed, rule documented.

How to check whether yours is exposed

List every public IP address you own, from your router, cloud console and ISP.
Check your firewall and router port-forward rules for 873.
Search your servers for the rsync daemon: look for an rsyncd.conf file and the rsync service.
Run the free web vulnerability scan on your domain as a first look from outside.

How to secure it

Close port 873 at the firewall unless there is a documented need.
Move transfers to rsync over SSH, with key-based login.
If a daemon is needed, bind it to localhost or a private address and reach it through an SSH tunnel, as the rsync manual suggests.
Make every module read-only where possible and require authenticated users with strong passwords (see the rsyncd.conf documentation for your version).
Restrict modules to named source addresses using the daemon’s access controls.
Update rsync to the patched versions listed by CERT/CC, and update any product that bundles it.
Document each inbound rule and remove it when the job ends.

FAQ

Does port 873 use encryption? No. The rsync manual says a direct daemon connection is not encrypted.

What is the safer alternative? Rsync over SSH, which authenticates and encrypts the connection.

Which advisory should I check? CERT/CC VU#952657, which covers CVE-2024-12084 and five others.

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan or see penetration testing.

Port 873 (rsync): what it is, how it is attacked and how to secure it