Summary
The CVE-2026-32885 ZipSlip fix added a symlink-target escape check to Untar, but the check rebases an ABSOLUTE symlink target into dest before validating (filepath.Join(dest, "/etc") stays lexically inside dest and passes), while the symlink is then created with the RAW absolute target via os.Symlink(file.Linkname, ...), so a malicious archive plants a host-absolute symlink and a following regular-file entry writes through it, restoring arbitrary host file create/overwrite (reaching $HOME rc-files, hence RCE). Confirmed at HEAD.
The defect (the symlink check is a no-op for absolute targets)
CVE-2026-32885 (fixed v1.25.2, commit 05cbe299) added a lexical containment check on the entry path and a NEW symlink-target validation. pkg/archive/archive.go, Untar, tar.TypeSymlink case:
if filepath.IsAbs(file.Linkname) {
resolvedTarget = filepath.Join(dest, file.Linkname) // line 298: absolute target REBASED into dest
} else {
resolvedTarget = filepath.Join(fullPathDir, file.Linkname)
}
if !strings.HasPrefix(filepath.Clean(resolvedTarget)+sep, filepath.Clean(dest)+sep) { // line 302
return ...escapes destination... // line 303
}
_ = os.Remove(fullPath) // line 307
err = os.Symlink(file.Linkname, fullPath) // line 310: writes the RAW LinknameFor an absolute Linkname like /Users/victim, line 298 computes filepath.Join(dest, "/Users/victim") = dest/Users/victim (lexically inside dest), so the escape check at line 302 PASSES. But line 310 creates the symlink with the raw file.Linkname, so the on-disk symlink dest/link points at the real host path /Users/victim. The value validated (rebased) is not the value written (raw): a check-one-thing / do-another divergence.
Write-through: the archive carries a second regular-file entry whose Name traverses the planted link (e.g. link/.zshrc). Its fullPath is lexically inside dest so the line-238 check passes (that check is purely lexical and does not resolve the symlink), then os.Create follows the planted symlink and overwrites /Users/victim/.zshrc on the host. Overwriting a shell rc-file, git hook, or cron entry yields code execution. Reachable via ddev add-on get <repo|url> (the exact remote-add-on vector the advisory names), and via ddev import-db / import-files. GitHub codeload tarballs preserve symlinks.
Verification
EXECUTED (go test driving the real Untar): a file was written OUTSIDE dest and Untar returned nil (VULNERABLE); a pre-existing host file was truncated and overwritten with the attacker payload; the negative controls (a relative ../ symlink escape, and a plain ../ file entry) are both correctly rejected, isolating the bug to the absolute-symlink branch. NOT verified: the end-to-end add-on get over the network (the caller chain is source-confirmed); Windows (reliable on macOS/Linux, DDEV's primary hosts). Unzip is NOT affected (tar-only).
Suggested fix
Reject absolute symlink targets outright (a dev-environment archive has no need to plant host-absolute symlinks), or validate the RAW target that will actually be written rather than a rebased copy. Additionally, resolve symlinks when validating each regular-file entry's parent so a write cannot traverse a previously-planted link (or extract to a staging dir and reject any entry whose realpath escapes). The lexical line-238 check does not defend against a planted symlink.
Tooling
AI assistance was used while investigating. The write-through is executed-verified with negative controls (an absolute-symlink entry plus a follow-up file entry wrote and overwrote files OUTSIDE dest while relative-escape and plain-ZipSlip controls were correctly rejected), and I confirmed at HEAD that Untar rebases an absolute symlink target into dest for the escape check (line 298) but creates the symlink with the raw absolute target (line 310).
References
arpitjain099 Reporter
Summary
The CVE-2026-32885 ZipSlip fix added a symlink-target escape check to Untar, but the check rebases an ABSOLUTE symlink target into dest before validating (filepath.Join(dest, "/etc") stays lexically inside dest and passes), while the symlink is then created with the RAW absolute target via os.Symlink(file.Linkname, ...), so a malicious archive plants a host-absolute symlink and a following regular-file entry writes through it, restoring arbitrary host file create/overwrite (reaching $HOME rc-files, hence RCE). Confirmed at HEAD.
The defect (the symlink check is a no-op for absolute targets)
CVE-2026-32885 (fixed v1.25.2, commit 05cbe299) added a lexical containment check on the entry path and a NEW symlink-target validation. pkg/archive/archive.go, Untar, tar.TypeSymlink case:
For an absolute Linkname like /Users/victim, line 298 computes filepath.Join(dest, "/Users/victim") = dest/Users/victim (lexically inside dest), so the escape check at line 302 PASSES. But line 310 creates the symlink with the raw file.Linkname, so the on-disk symlink dest/link points at the real host path /Users/victim. The value validated (rebased) is not the value written (raw): a check-one-thing / do-another divergence.
Write-through: the archive carries a second regular-file entry whose Name traverses the planted link (e.g. link/.zshrc). Its fullPath is lexically inside dest so the line-238 check passes (that check is purely lexical and does not resolve the symlink), then os.Create follows the planted symlink and overwrites /Users/victim/.zshrc on the host. Overwriting a shell rc-file, git hook, or cron entry yields code execution. Reachable via ddev add-on get <repo|url> (the exact remote-add-on vector the advisory names), and via ddev import-db / import-files. GitHub codeload tarballs preserve symlinks.
Verification
EXECUTED (go test driving the real Untar): a file was written OUTSIDE dest and Untar returned nil (VULNERABLE); a pre-existing host file was truncated and overwritten with the attacker payload; the negative controls (a relative ../ symlink escape, and a plain ../ file entry) are both correctly rejected, isolating the bug to the absolute-symlink branch. NOT verified: the end-to-end add-on get over the network (the caller chain is source-confirmed); Windows (reliable on macOS/Linux, DDEV's primary hosts). Unzip is NOT affected (tar-only).
Suggested fix
Reject absolute symlink targets outright (a dev-environment archive has no need to plant host-absolute symlinks), or validate the RAW target that will actually be written rather than a rebased copy. Additionally, resolve symlinks when validating each regular-file entry's parent so a write cannot traverse a previously-planted link (or extract to a staging dir and reject any entry whose realpath escapes). The lexical line-238 check does not defend against a planted symlink.
Tooling
AI assistance was used while investigating. The write-through is executed-verified with negative controls (an absolute-symlink entry plus a follow-up file entry wrote and overwrote files OUTSIDE dest while relative-escape and plain-ZipSlip controls were correctly rejected), and I confirmed at HEAD that Untar rebases an absolute symlink target into dest for the escape check (line 298) but creates the symlink with the raw absolute target (line 310).
References