GPU VulnDB

Database/Control plane, storage & DevOps

rsync SSL modes: server TLS certificates are not validated, so an on-path attacker can read the transfer

CVSS 7.6CVE-2026-70454Control plane, storage & DevOpscurated

Impact

rsync 3.2.0 through 3.2.3 in openssl mode, and the rsync-ssl wrapper through 3.4.4 in stunnel mode, do not validate the server certificate against a trusted CA and do not check hostname matching. An attacker positioned on the network path can present a self-signed certificate, terminate the session, and read or modify everything in transit without the client noticing. For a GPU operator the exposed asset is bulk data movement: dataset and checkpoint staging between sites, model artifacts pulled into a cluster, and backup streams. Silent modification is the sharper end of this, because a tampered training dataset or checkpoint is not something a checksum-free rsync run will surface. Only the TLS transports are affected; rsync over SSH, the far more common deployment, is not in scope of this record.

Who can reach it

An on-path network attacker between the rsync client and the rsync daemon, for sessions that use openssl mode or the rsync-ssl stunnel wrapper. No credentials are required; the CVSS 4.0 vector notes passive user involvement, consistent with the victim initiating the transfer.

What to do

Upgrade rsync to 3.5.0, which is the release the project ties the fix to. This is a package update to a command-line tool, so there is no daemon to restart on the client side and no node downtime; the next transfer uses the fixed binary. Where a rebuild is not immediate, move the affected transfers to rsync over SSH, which does not use this code path.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.