Restore: stale symlink can cause out-of-repo write (CWE-59)

quiet.art · 4 July 2026 18:14

Please describe what you are doing to trigger the bug:

Migrating my revisions out of duplicacy and into restic.

In this case, revision 1 created /repo/etc/resolv.conf which was an absolute symlink resolving outside of the repository. Revision 2 then restored /repo/etc/resolv.conf, which was a regular file. Rather than replace the symlink located at /repo/etc/resolv.conf, duplicacy followed the symlink, overwriting the target (which happened to live outside of the repository). Oops.

Please describe what you expect to happen (but doesn’t):

(1) Never blindly follow symlinks during restore
(2) Definitely don’t ever write outside of the repository root during a restore

The restore behavior in general surrounding this situation (on-disk object is different type than revision object) is inconsistent at best, just plan buggy at worst. For example, even with -overwrite and -delete, duplicacy will not replace a non-empty on-disk directory with a file during a restore. So in some cases, it’s actually impossible to get duplicacy to restore a repository to a particular revision state.

But for now, it should at least not overwrite non-repository files.

github.com/gilbertchen/duplicacy

restore: stale symlink can cause out-of-repo write (CWE-59)

gilbertchen:master ← anonymouspage:bugfix/symlink-escape

opened 06:00PM - 04 Jul 26 UTC

anonymouspage

+127 -0

When restore writes a non-symlink entry to a path where a symlink already exists… on disk, it opens the destination with symlink-following calls (`os.Open` / `os.OpenFile`, no `O_NOFOLLOW`) and writes the entry's contents through the symlink to its target, which may be outside the restore directory (CWE-59). The on-disk symlink need not come from a prior backup; a less-trusted user can plant one so a root restore `-overwrite` writes through it (confused deputy). Proof of concept ``` mkdir /repo && cd /repo duplicacy init repo <storage> echo foo > x duplicacy backup mkdir /recovery && cd /recovery duplicacy init repo <storage> # same <storage> as above echo my_important_data > /tmp/victim ln -s /tmp/victim x # absolute target, outside /recovery duplicacy restore -r 1 -overwrite cat /tmp/victim # prints "foo"; /tmp/victim overwritten ``` Fix: before restoring an entry, if the on-disk path is a symlink (checked with Lstat, so it is never followed) but the snapshot entry is not, remove the symlink; gated on `-overwrite`, consistent with how restore already handles an existing file whose contents differ.