CVE-2024-12084

What it actually does

CVE-2024-12084 is a network-exploitable heap-based buffer overflow in the rsync daemon caused by improper handling of attacker-controlled checksum length values. During rsync protocol negotiation or transfer processing, a malicious peer can cause the daemon to use an s2length value larger than the fixed 16-byte sum2 buffer, resulting in an out-of-bounds heap write. Because the vulnerable service can be reached over the network and exploitation requires no authentication or user interaction, successful exploitation may enable remote code execution, process compromise, memory corruption, service crashes, data theft, or modification of files accessible to the rsync daemon process.

Why it matters to the business

Organizations exposing rsync services could face full compromise of systems running vulnerable rsync daemon instances, especially where rsync is used for backups, software distribution, mirroring, or file synchronization. A successful attack could interrupt backup and replication operations, corrupt synchronized data, expose sensitive files, or allow attackers to pivot from a trusted file-transfer host. The CVSS score is critical and EPSS is high, indicating meaningful likelihood of exploitation in the wild even though it is not currently listed in CISA KEV and no ransomware use is reported. Because rsync is widely packaged across Linux and Unix-like ecosystems, exposure may exist in appliances, distributions, containers, and inherited dependencies as well as directly managed servers.

How an attack unfolds

An attacker first identifies systems with the rsync daemon reachable over the network, commonly on TCP port 873 or through service banners and rsync module listings. The attacker then initiates an rsync protocol session and sends crafted checksum negotiation or transfer data that manipulates the checksum length field to exceed the fixed buffer size used by the daemon. When the vulnerable code copies or writes digest data using the attacker-controlled length, heap memory adjacent to the sum2 buffer is overwritten. Depending on memory layout, target version, hardening features, and exploit reliability, this may crash the rsync daemon or allow controlled memory corruption leading to arbitrary code execution in the context of the rsync daemon. If code execution is achieved, the attacker can access files permitted by rsync module configuration, alter synchronized content, stage malware in mirrored directories, or use the host as a foothold for lateral movement.

How to fix it

Upgrade rsync packages from the operating system or vendor security channel to a version that includes the fix for CVE-2024-12084. Because fixed versions were not provided in the input, follow the relevant advisory for each affected distribution or product, including Red Hat Enterprise Linux, AlmaLinux, Arch Linux, Gentoo, NixOS, SUSE Linux, SmartOS, and Samba/rsync package maintainers. Restart the rsync daemon after patching so the fixed binary is loaded. If immediate patching is not possible, disable rsync daemon mode, restrict access to trusted management or replication networks only, block inbound TCP/873 from untrusted sources, require SSH-based rsync instead of daemon mode where feasible, and review rsync module permissions to minimize file exposure. Run the daemon with least privilege, use chroot or sandboxing where supported, and remove unauthenticated or writable modules that are not strictly required.

How to confirm the fix worked

Confirm the installed rsync package version is the vendor-fixed build for the relevant platform using the system package manager and vendor advisory metadata. Verify that the running daemon process was restarted after update and is using the patched executable, not an older deleted binary still resident in memory. Validate network exposure by scanning externally and internally for rsync daemon listeners, especially TCP/873, and confirm that only authorized sources can connect. Attempt benign rsync protocol/module enumeration from an untrusted network segment to ensure firewall and access controls block access. Review configuration files such as rsyncd.conf to confirm unnecessary modules, anonymous access, and writable shares are disabled or restricted. Where vulnerability scanners support this issue, run authenticated package checks rather than relying only on remote banner detection, because distributions may backport fixes without changing upstream version strings.

Typical attack path

1. Scan the internet or internal networks for exposed rsync daemon services, especially TCP/873.
2. Confirm rsync service availability through banner behavior, module enumeration, or protocol negotiation.
3. Initiate a malicious rsync session with crafted checksum length values that exceed the expected fixed checksum buffer.
4. Trigger the heap-based out-of-bounds write during checksum handling.
5. Cause a daemon crash for denial of service or shape heap memory to achieve remote code execution.
6. Use the compromised rsync daemon privileges to read, modify, delete, or plant files within accessible rsync modules.
7. Attempt persistence, credential discovery, or lateral movement from the compromised file synchronization host.

How to detect it

To determine whether exploitation may already have occurred, review rsync daemon logs, system authentication logs, syslog/journald, crash reports, endpoint telemetry, and network flow records. Focus on inbound connections to TCP/873 or custom rsync daemon ports from unfamiliar addresses, repeated connection attempts, malformed or short-lived sessions, module enumeration followed by crashes, and daemon restarts. Look for segmentation faults, heap corruption messages, core dumps, abnormal exit signals, or service manager restart loops involving rsync or rsyncd. On Linux systems, inspect /var/log/rsyncd.log, /var/log/syslog, /var/log/messages, journalctl output for rsync services, auditd process execution logs, and crash directories such as /var/crash or systemd-coredump storage. If endpoint detection data is available, investigate any rsync daemon spawning shells, interpreters, download tools, compilers, or unexpected child processes. File integrity monitoring should be reviewed for unexpected changes in rsync-exposed module directories, especially newly added executables, scripts, web shells, SSH keys, cron jobs, or modified software distribution artifacts. Network detection should flag unsolicited rsync daemon negotiation from the internet, high-volume scanning for TCP/873, and unusual rsync traffic from geographies or autonomous systems not associated with normal replication partners. No public exploit-specific byte sequence is provided in the input, so detections should combine service exposure, crash artifacts, anomalous protocol use, and post-exploitation behavior.

• tcp/873
• rsyncd.conf
• /etc/rsyncd.conf
• /var/log/rsyncd.log
• rsyncd
• rsync --daemon
• rsync.service
• rsync daemon
• segfault
• Segmentation fault
• core dumped
• systemd-coredump
• /var/lib/systemd/coredump
• /var/crash
• kernel: rsync
• kernel: rsyncd
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid pointer
• double free or corruption
• corrupted double-linked list
• rsync error: error in rsync protocol data stream
• rsync error: unexplained error
• rsync: connection unexpectedly closed
• rsyncd.secrets
• /etc/rsyncd.secrets

What your security team should do

• Prioritize patching all internet-facing rsync daemon instances and systems that support backup, replication, mirrors, CI/CD artifact distribution, or sensitive file synchronization.
• Inventory rsync daemon exposure across servers, appliances, containers, and managed images; do not limit review to systems where rsync is intentionally advertised.
• Restrict TCP/873 and any custom rsync daemon ports to trusted peers using host firewalls, network ACLs, VPNs, or security groups.
• Disable rsync daemon mode where not required and prefer rsync over SSH with strong authentication for administrative transfers.
• Review rsync module configuration for anonymous access, writable modules, broad filesystem paths, weak secrets files, and excessive daemon privileges.
• Restart patched daemons and verify no vulnerable rsync processes remain running from deleted or old binaries.
• Increase monitoring for rsync crashes, unusual module enumeration, unexpected source IPs, abnormal file writes, and suspicious child processes spawned by the rsync daemon.
• Treat unexplained rsync daemon crashes on exposed systems as potentially malicious until investigated, given the critical unauthenticated remote memory corruption profile and high EPSS score.