HSEC-2026-0014: Arbitrary file write via path traversal in unpackToDir
Arbitrary file write via path traversal in unpackToDir
Codec.Archive.unpackToDir extracts a tar (or other archive supported by the libarchive C library) from a ByteString into a directory. unpackToDirLazy is the streaming variant; both funnel through the same internal unpackEntriesFp routine.
unpackEntriesFp joined each entry's name onto the destination directory with System.FilePath.(</>) without validating the name. Entry names starting with .. sequences therefore escape the destination: fp </> "../../../../etc/x" resolves outside the extraction root. The joined path is written back into the archive entry (archiveEntrySetPathname) and handed to libarchive's archivereadextract with no ARCHIVEEXTRACTSECURE flags, so neither the Haskell layer nor the C library rejects the traversal. The .. check is not limited to tar archives: any format whose entry names libarchive reports verbatim is affected. Extraction result codes were also discarded, so write failures could pass unnoticed.
An attacker who can supply an archive to a service that extracts it with these APIs gains an arbitrary file write with the privileges of the extracting process. A demonstrated escalation (verified in a container): an archive with member ../../../../etc/profile.d/zz-poc-zipslip.sh plants a shell script sourced by every subsequent login shell, converting the file write into code execution when any user logs in.
The reported traversal is fixed in libarchive-3.0.6.0, which fails with ArchiveFatal when an entry path begins with .. (commit 325a2296379905557de1fa21b28d86f34bab2441).
Users should upgrade to libarchive-3.0.6.0 or later. If pinned to an older version, validate entry names before extraction (reject absolute paths and any path containing a .. component) or extract inside a sandboxed directory.
External vulnerability reported by Akash Sebastian (justabughunter).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
hackage/libarchiveto a version that resolves this vulnerability.Fixed in 3.0.6.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.0.6.0 - Compensating control
If using an older libarchive version, reject absolute entry paths and paths containing a `..` component before extraction, or extract into a sandboxed directory.
Event History
Frequently Asked Questions
Which extraction APIs are affected?
Both Codec.Archive.unpackToDir and the streaming unpackToDirLazy variant are affected because they use the same internal unpackEntriesFp routine.
Is the issue limited to tar archives?
No. Any archive format for which libarchive reports entry names verbatim can be affected.
What must an attacker be able to do to exploit this?
The attacker must be able to supply an archive that the application extracts using the affected APIs. They can then write files with the privileges of the extracting process.
Can extraction result handling be relied on to identify unsuccessful writes?
No. Extraction result codes were discarded, so write failures could pass unnoticed.