<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><TITLE>rsync</TITLE><style>.security { color: red; }h3 { margin-bottom: 0px; }.date { color: #D25A0B; }</style></HEAD><!--#include virtual="header.html" --> <H2 align="center">Rsync Security Advisories</H2> <p>If you are running an rsync older than 3.5.0, you should upgrade. 3.5.0fixes every issue listed on this page. <p>If you cannot upgrade, the advisories below give the affected versions andthe conditions each issue needs. Several are only reachable in a non-defaultconfiguration, and some of the older ones can be mitigated from rsyncd.confwithout an upgrade. <p><a name="s3_5_0"></a><hr><h3>Security fixes in 3.5.0</h3><i class=date>August 13th, 2026</i> <p>Rsync 3.5.0 fixes 33 security issues found during a focused audit of rsync'spath handling and daemon protocol, a companion daemon-protocol fuzzing pass,and reports from external researchers. All releases up to and including 3.4.4are affected, except where an individual advisory gives a narrower range &mdash;many do, so check the advisory before deciding what needs patching. <p>Upgrade to 3.5.0. See the<a href="https://download.samba.org/pub/rsync/NEWS#3.5.0">3.5.0 NEWS</a> for thefull changelog, and the<a href="https://github.com/RsyncProject/rsync/security/advisories">GitHubsecurity advisories</a> for the individual reports. <p>Several of these are only reachable in a non-default configuration &mdash; adaemon with "use chroot = no", a writable module, an <b>rrsync</b> restrictedaccount, "proxy protocol = true", or a configured name converter or exec hook.The advisories say which. <ul><li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-9cgc-64g4-3gv5">CVE-2026-53783</a> (HIGH) &mdash; rrsync restricted-directory escape (validation-vs-exec race + unsafe option allowlist)<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-ffg2-fr5g-3rxw">CVE-2026-53784</a> (HIGH) &mdash; Daemon module-root chdir escape under "use chroot = no"<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-pph3-7xmf-rrqg">CVE-2026-53785</a> (HIGH) &mdash; --relative implied-parent creation escapes the destination tree<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-mrc3-6cwx-hch6">CVE-2026-53786</a> (MEDIUM) &mdash; Daemon --filter merge file bypasses the module filter list<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-p4c5-8c68-5fjq">CVE-2026-53788</a> (MEDIUM) &mdash; Daemon name-converter accepts newline-bearing names into its line protocol<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-fxwg-7hmf-xh5q">CVE-2026-53789</a> (MEDIUM) &mdash; Malicious sender expands --delete scope by reclassifying an implied parent<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-5hcf-7xxm-rmqq">CVE-2026-53790</a> (HIGH) &mdash; Command / argument injection via unquoted peer- or host-controlled values<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-h2q9-5fr8-w635">CVE-2026-53791</a> (CRITICAL) &mdash; PROXY-protocol mode lets a direct client spoof the daemon's source address<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-cg57-rp9g-56hw">CVE-2026-53792</a> (MEDIUM) &mdash; Receiver-supplied zero checksum block length drives sender matching negative<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-wj7w-vh23-mm44">CVE-2026-53793</a> (HIGH) &mdash; Chroot "/./" inner-module escape via a parent-component symlink<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-p827-vwcp-m964">CVE-2026-53794</a> (MEDIUM) &mdash; Remote peer disables the per-allocation sanity cap via --max-alloc=0<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-m9vj-637x-v6pq">CVE-2026-53795</a> (HIGH) &mdash; Receiver write escape via an absolute --temp-dir / --link-dest disabling rename/link confinement<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-w75h-ccff-w53m">CVE-2026-53796</a> (MEDIUM) &mdash; Non-daemon receiver destination-chdir symlink race (TOCTOU)<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-3jj3-qvc7-jp6x">CVE-2026-53797</a> (MEDIUM) &mdash; Sender source-tree parent-component symlink race -&gt; out-of-tree disclosure<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-hx7p-3gvv-pqgv">CVE-2026-53798</a> (MEDIUM) &mdash; Daemon name-converter empty response maps an unknown name to uid/gid 0<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-phxh-hjqv-39c9">CVE-2026-53799</a> (MEDIUM) &mdash; Receiver ACL/xattr application follows a symlink-race -&gt; arbitrary ACL set (local privilege escalation)<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-v3vw-pvpg-chwh">CVE-2026-53800</a> (MEDIUM) &mdash; Sender --remove-source-files unlink follows a parent-component symlink race -&gt; arbitrary file deletion outside the source tree<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-mch3-qr4p-chgm">CVE-2026-53801</a> (MEDIUM) &mdash; Sender/daemon directory-scan enumeration escapes the transfer root / module -&gt; out-of-tree disclosure<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-4mfr-8jrv-49x4">CVE-2026-53802</a> (HIGH) &mdash; Arbitrary file read / transfer-shaping via symlinked operator-supplied input files<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-g9f4-7q66-9582">CVE-2026-53803</a> (HIGH) &mdash; Arbitrary file write / privilege escalation via symlinked operator-supplied output paths<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-6692-28cx-wpqq">CVE-2026-70452</a> (HIGH) &mdash; `hosts deny` fails OPEN when a configured hostname cannot be resolved, admitting the host it was meant to block<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-8x5r-mjx8-83hv">CVE-2026-70453</a> (HIGH) &mdash; Quadratic CPU exhaustion in hash_search() from a crafted equal-weak-checksum chain<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-3c3x-ww2w-5r5p">CVE-2026-70454</a> (MEDIUM) &mdash; rsync-ssl establishes an unauthenticated TLS connection (no CA verification; no stunnel hostname binding)<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-rjvj-qgqg-cvx9">CVE-2026-70455</a> (HIGH) &mdash; Peer-controlled Zstandard worker exhaustion on an rsync daemon<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-78jc-79jv-v6rw">CVE-2026-70456</a> (HIGH) &mdash; Remote out-of-bounds heap write in read_args() when the argument count lands exactly on maxargs<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-pg7g-xqmr-xpfh">CVE-2026-70457</a> (MEDIUM) &mdash; Attacker-chosen-offset write in parse_size_arg() error formatting<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-gg3m-4m9m-268h">CVE-2026-70458</a> (HIGH) &mdash; Out-of-bounds write from a FLAG_HLINKED file entry accepted without -H<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-p4v4-qxw9-q72m">CVE-2026-70459</a> (MEDIUM) &mdash; Per-connection daemon child crash from a crafted first incremental file list with a non-directory transfer root<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-w3xf-j2r2-gv4x">CVE-2026-70460</a> (HIGH) &mdash; Daemon module-root escape through a peer-supplied --partial-dir / --backup-dir resolving via an in-module symlink<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-jhxm-j4mq-3fj4">CVE-2026-70461</a> (HIGH) &mdash; Peer-driven one-byte heap out-of-bounds write in add_implied_include()<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-j9wh-5jmp-2m64">CVE-2026-70462</a> (MEDIUM) &mdash; Peer-supplied MSG_IO_TIMEOUT defeats the client's own I/O timeout (signed overflow, and a non-positive value)<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-pfj8-79vq-xgvr">CVE-2026-70463</a> (HIGH) &mdash; "auth users" ignores documented comma-only parsing, silently skipping a deny/read-only rule<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-hrwq-ccf7-rw5m">CVE-2026-70464</a> (HIGH) &mdash; Unauthenticated pre-transfer handshake DoS locks out an rsync daemon module</ul> <p><a name="s3_4_3"></a><hr><h3>Security fixes in 3.4.3</h3><i class=date>May 20th, 2026</i> <p>Rsync 3.4.3 fixes six security issues. Versions 3.4.2 and earlier areaffected. See the<a href="https://download.samba.org/pub/rsync/NEWS#3.4.3">3.4.3 NEWS</a>. <ul><li>CVE-2026-29518 &mdash; TOCTOU symlink race allowing local privilegeescalation in daemon mode without chroot. Only "use chroot = no" is exposed.<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-g37v-g3gj-pmwq">CVE-2026-43618</a>&mdash; integer overflow in compressed-token decoding, allowing a malicioussender to disclose process memory to an authenticated daemon peer.<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-28pw-r563-rxvm">CVE-2026-43620</a>&mdash; out-of-bounds read in the receiver, letting a malicious server crash anyclient pulling from it.<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-4h9m-w5ff-j735">CVE-2026-43619</a>&mdash; symlink races on the remaining path-based system calls under"use chroot = no", generalising CVE-2026-29518.<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-rjfm-3w2m-jf4f">CVE-2026-43617</a>&mdash; hostname ACL bypass on a daemon with "daemon chroot" set where thechroot lacks the libc resolver files.<li><a href="https://github.com/RsyncProject/rsync/security/advisories/GHSA-8f85-j2cv-59m8">CVE-2026-45232</a>&mdash; off-by-one stack out-of-bounds write parsing an HTTP CONNECT proxyresponse. Client-side, and only when RSYNC_PROXY is set.</ul> <p><a name="s3_4_2"></a><hr><h3>Security-related fixes in 3.4.2</h3><i class=date>April 28th, 2026</i> <p>Several security-relevant defects were fixed in 3.4.2. None were assigned aCVE: rsync's fork-per-connection design scopes each of them to the attacker'sown connection, which is equivalent to the client closing the socket itself.They were fixed as a matter of hygiene and to reduce the chance of a futureexploitable combination. A signed integer overflow in the PROXY protocol v2header parser, an invalid access to the files array, and a negative token valueaccepted by the compressed-stream decoder. See the<a href="https://download.samba.org/pub/rsync/NEWS#3.4.2">3.4.2 NEWS</a>. <p><a name="s3_4_0"></a><hr><h3>Security fixes in 3.4.0</h3><i class=date>January 14th, 2025</i> <p>Rsync 3.4.0 fixes six security issues, the most serious of which allows amalicious server to write outside the destination directory on a client thatpulls from it. Versions 3.3.0 and earlier are affected. See the<a href="https://download.samba.org/pub/rsync/NEWS#3.4.0">3.4.0 NEWS</a>. <ul><li>CVE-2024-12084 &mdash; heap buffer overflow in the daemon's checksumhandling.<li>CVE-2024-12085 &mdash; information leak from uninitialised stack memorywhen comparing file checksums.<li>CVE-2024-12086 &mdash; a malicious server could enumerate and readarbitrary files from the client.<li>CVE-2024-12087 &mdash; a malicious server could write outside thedestination directory using --inc-recursive.<li>CVE-2024-12088 &mdash; --safe-links failed to verify symlink targetscontaining other symlinks, allowing a path-traversal write.<li>CVE-2024-12747 &mdash; symlink race in the sender when handlingregular files.</ul> <p><a name="s3_2_5"></a><hr><h3>Improved file-list validation in 3.2.5</h3><i class=date>August 14th, 2022</i> <p>If you are running an rsync older than 3.2.5 and pulling files from anuntrusted server, upgrade to 3.2.5 to get some added file-list validation rulesthat should prevent the sender from sneaking in extra top-level argumentsand/or including files/dirs that should have been filtered out by the client'sfilter rules. Fixes CVE-2022-29154. <p><a name="s3_2_5-2"></a><hr><h3>Zlib memory corruption bug in rsync 2.6.6 - 3.2.4</h3><i class=date>August 14th, 2022</i> <p>If your rsync is configured to use the bundled zlib, you should upgrade to3.2.5 which contains the official zlib fix for a buffer overrun bug that wasdetailed in CVE-2022-37434. While you're at it, be sure to update your system'szlib. <p><a name="s3_2_4"></a><hr><h3>Zlib memory corruption bug in rsync 2.6.6 - 3.2.3</h3><i class=date>April 15th, 2022</i> <p>If your rsync is configured to use the bundled zlib, you should upgrade to3.2.4 which contains the official zlib fix for a memory corruption bug that wasdetailed in CVE-2018-25032. While you're at it, be sure to update your system'szlib. <p><a name="s3_1_3"></a><hr><h3>File-list validation in 3.1.3</h3><i class=date>January 28st, 2018</i> <p>If you are using a version of rsync older than 3.1.3 as a client andreceiving xattrs from an rsync server that you might not fully trust, amalicious (modified) server could send a non-null-terminated xattr name tooverflow the xattr read buffer. <p>If you are running a writable rsync daemon older than 3.1.3, you should adda rule "refuse options = protect-args" if you don't fully trust the users whoare sending you files. <p><a name="s3_1_2"></a><hr><h3>File-list validation in 3.1.2</h3><i class=date>December 21st, 2015</i> <p>If you're using a version of rsync older than 3.1.2 as a client andreceiving files from an rsync server that you might not fully trust, thisversion adds extra checking to the file list to prevent the sender fromtweaking the paths and/or the transfer requests in a way that could causea file to be received outside the transfer destination. <p><a name="s3_0_2"></a><hr><h3>Xattr security fix in 3.0.2</h3><i class=date>April 8th, 2008</i> <p>If you're using a version of rsync from 2.6.9 to 3.0.1 that has extendedattribute (xattr) support enabled, you should upgrade to 3.0.2 to avoid apotential buffer overflow problem.  All 3.x versions have the potential tosupport xattrs (depending on OS availability and the configure options used),but version 2.6.9 had to be patched for this support.  You can run the command"rsync --version" and look for the string "xattrs" (as long as it is not"no&nbsp;xattrs") to see if your rsync is affected. <p>For those running affected versions, there is<a href="https://download.samba.org/pub/rsync/security/rsync-3.0.1-xattr-alloc.diff">apatch with the fix available</a>. <p>Those running a writable rsync daemon can opt to refuse the "xattrs" optionas a way to avoid the problem without an upgrade: <blockquote><pre>refuse options = xattrs</pre></blockquote> <p>(If you already refuse options, be sure to append "xattrs" to your existingconfig parameter rather than adding another refuse directive.) <p><a name="s3_0_0"></a><hr><h3>Daemon security fixes in 3.0.0 (with patches for 2.6.9)</h3><i class=date>First published on November 28th, 2007;<br>Updated on December 16th, 2007;<br>Item 3 added on February 15th, 2008</i> <p>Three security advisories affect people who run a <b>writable</b> rsyncdaemon:  The first affects only those with "use chroot = no" (which is not avery safe combination in general), the second affects a daemon that hasdaemon-excluded files that are being hidden in a module's hierarchy, andthe third affects only those with "use chroot = yes".Included are simple config-change suggestions that should help you toavoid the security issues and patches that make things safer.These advisories affect all rsync versions. <h4>1. Daemon advisory for "use chroot = no"</h4> <p>If you are running a writable rsync daemon with "use chroot = no", thereis at least one way for someone to trick rsync into creating a symlinkthat points outside of the module's hierarchy. <p>This means that if you are allowing access from users who you don'ttrust, that you should either figure out a way to turn on "use chroot",or configure the daemon to refuse the "links" option (see "refuseoptions" in the rsyncd.conf manpage) which will disable the ability ofthe rsync module to receive symlinks.  After doing so, you should alsocheck that any existing symlinks in the daemon hierarchy are safe. <p>Starting with the 3.0.0-pre6 release, there is a new daemon parameteravailable: "munge symlinks".  This allows an rsync daemon to acceptsymlinks and return them intact (with even a leading slash still there,which is new for a non-chroot daemon), but will not allow the symlinksto be used while they are in the daemon's hierarchy. <p>For those running2.6.9, there is<a href="https://download.samba.org/pub/rsync/security/rsync-2.6.9-munge-symlinks.diff">apatch for 2.6.9 to implement this parameter</a>. <p>Any admin applying that patch should read the "munge symlinks" sectionof the modified rsyncd.conf manpage for more information.  You can alsoread about this parameter in the<a href="https://download.samba.org/pub/rsync/rsyncd.conf.html">rsyncd.confmanpage from a 3.x version</a>. <h4>2. Daemon advisory for daemon excludes</h4> <p>If you are running a writable rsync daemon that is using one of the"exclude", "exclude from", or "filter" parameters in the rsyncd.conf fileto hide data from your users, you should be aware that there are tricksthat a user can play with symlinks and/or certain options that can allowa user that knows the name of a hidden file to access it or overwrite it(if file permissions allow that). <p>You can avoid the symlink problem using the suggestions in the advisoryabove. <p>When a daemon has "use chroot = no" set , there was some buggyexclude-checking for these options: <code>--compare-dest</code>,<code>--link-dest</code>, <code>--copy-dest</code>, <code>--partial-dir</code>,<code>--backup-dir</code>, <code>--temp-dir</code>, and<code>--files-from</code>.  These are fixed in the 3.0.0pre7 release.  Forthose running 2.6.9, there is <ahref="https://download.samba.org/pub/rsync/security/rsync-2.6.9-daemon-exclude.diff">a patch for2.6.9</a> to fix these checks. <p>Some of the above options can still cause problems if an excludedsub-directory or filename is inside the option's directory hierarchy and thenames of a transferred file clashes with it.  The affected options are thevarious <code>--*-dest</code> options (of which only <code>--link-dest</code>is particularly worrisome),<code>--backup-dir</code>, and <code>--partial-dir</code>. <p>You can avoid these sub-path problems by putting the following "refuseoptions" setting into your rsyncd.conf file: <blockquote><pre>refuse options = link-dest backup-dir partial-dir</pre></blockquote> <p>Those who aren't using an rsync with the latest exclude fixes may want to addsome of the other affected options as well. <h4>3. Daemon advisory for "use chroot = yes"</h4> <p>If you are running a writable rsync daemon with "use chroot = yes", youshould take care that users cannot upload their own library files and attemptto load them. <p>Beginning with rsync 3.0.0pre10, you can specify an inside-chroot path thatmakes the top of the transfer a subdirectory inside the chroot area, and thatautomatically makes library loading occur outside the transfer area (assumingyou didn't pick an unwise subdirectory name for the transfer area and youdon't have symlinks that point outside the transfer area). <p>If that solution is not good for you, the easiest way to protect your daemonis to create some appropriate directories in the top of your module's pathhierarchy, such as "/etc", "/lib", and "/usr" (and any other top-level dirsthat might be in the load path), chown those directories to some other userthan the one that the module runs as (so that rsync will not be able to writefiles there, assuming that it is not run as root), and then hide the dirs usingan exclude directive (either add a new one or extend your existing one): <blockquote><pre>exclude = /etc /lib /usr</pre></blockquote> <p>Doing all that will assure you that no user will be able to use rsync toupload a library that can be potentially loaded while rsync is attempting toperform an action, such as translating a username.  You can feel free to puttrusted libraries that you want rsync to access in the protected hierarchies,as desired. <p>Also available in rsync 3.0.0pre10 is a new daemon parameter that allows youto avoid the accessing of user/group-name translation libraries by a chrootedrsync:  the "numeric ids" daemon parameter lets you turn on a forcednumeric-only mode.  The default for a chroot module is to enable thisparameter, while the default for a non-chroot module is to disable it. <p>For those running 2.6.9, there is <ahref="https://download.samba.org/pub/rsync/security/rsync-2.6.9-daemon-ids.diff">a patch for2.6.9</a> to add the "numeric ids" daemon config parameter.  (The patch willonly apply cleanly if you've already applied the munge-symlinks diff mentionedabove.) <p><a name="s2_6_8"></a><hr><h3>Xattr security fix in 2.6.8</h3><i class=date>April 22th, 2006</i> <p>If you're using a version of rsync prior to 2.6.8 that was patched toinclude extended attribute (xattr) support, you should upgrade to 2.6.8 orlater to avoid a potential buffer overflow problem. <p><a name="s2_6_6"></a><hr><h3>Zlib security fix in 2.6.6</h3><i class=date>July 28th, 2005</i> <p>If you're using a version of rsync prior to 2.6.6, there is a potentialnull-pointer security bug in the zlib code.  You can avoid its affect in anrsync daemon situation by configuring rsync to refuse the "compress" option. <p><a name="s2_6_3"></a><hr><h3>Daemon path-sanitizing fix in 2.6.3</h3><i class=date>August 12th, 2004</i> <p>There is a path-sanitizing bug that affects daemon-mode inrsync versions prior to 2.6.3, but only if "use chroot" is disabled.  Itdoes <b>not</b> affect the normal send/receive filenames that specify whatfiles should be transferred (this is because these names happen to getsanitized twice, and thus the second call removes any lingering leadingslash(es) that the first call left behind).  It does affect certainoption paths that cause auxiliary files to be read or written. <p>One potential fix that doesn't require recompiling rsync is to set"use chroot = true" for all the modules in the rsyncd.conf file. <p><a name="s2_6_1"></a><hr><h3>Daemon security fix in 2.6.1</h3><i class=date>April 26th, 2004</i> <p>There is a security problem in all versions prior to 2.6.1 that affects onlypeople running a read/write daemon with "use chroot" disabled.  If the user privsof a module in the daemon config is anything above "nobody", you are at riskof someone crafting an attack that could write a file outside of the module's"path" setting (where all its files should be stored).  Please either enablechroot or upgrade to 2.6.1.  People not running a daemon, running a read-onlydaemon, or running a chrooted daemon are totally unaffected. <p><a name="s2_5_7"></a><hr><h3>Memory overflow fix in 2.5.7</h3><i class=date>December 4th, 2003</i> <p>Rsync versions prior to 2.5.7 contain a heap overflow vulnerability thatcould be used to remotely run arbitrary code, but this only affects the use ofrsync as an "rsync daemon" (where rsync handles incoming socket connections,typically on port 873). <!--#include virtual="footer.html" --><br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;<br>&nbsp;