Does zipfile.ZipFile.extractall stop archive members from escaping the destination?

## Two archive modules, two different security stories `tarfile` and `zipfile` sit next to each other in the standard library and are routinely spoken of as interchangeable, but their extraction risks are not the same, and the mitigations do not transfer. `tarfile` needed the PEP 706 extraction filters because tar is a *filesystem* format: symlinks, hard links, device nodes, ownership and modes are all faithfully reproduced. `zipfile` never reproduced most of that, so it took a narrower route — it cleans member names and ignores the rest of the metadata. ## What extraction actually does to a member name `ZipFile.extractall()` loops over the archive and calls `ZipFile.extract()` for each member, and it is `extract()` that carries the protection. Before writing, it: * strips a Windows drive letter or UNC share prefix from the member name; * strips leading separators, so `/abs/rooted.txt` becomes `abs/rooted.txt`; * removes **every** `..` component, so `../../etc/cron.d/x` becomes `etc/cron.d/x`; * on Windows, replaces characters that are illegal in a filename with underscores. The result is joined onto the destination. So the classic escape-by-name against `extractall()` does not escape: the attacker gets to choose a path *inside* your destination, including creating deep subdirectories and overwriting a file you put there, but not a path above it. That last part still matters — if your destination is a directory the service reads configuration or templates from, overwriting inside it is quite enough. ## Symlinks and permissions are dropped, not honoured A zip member can record a Unix mode in the high half of `ZipInfo.external_attr`, including the symlink type bits. CPython's extractor ignores that field on the way out: * A member flagged as a symlink is written as a **regular file whose content is the target path**. There is therefore no escape-by-link against `zipfile`, and also no round-trip: an archive of a tree containing symlinks does not unpack back into symlinks. * Stored permission bits are not applied either. A member archived as mode `0o755` extracts with your process's default file permissions, which regularly surprises people unpacking a release archive and finding the entry-point script non-executable. This is why `zipfile` has no `filter` parameter and why looking for one is a sign the candidate has mapped `tarfile`'s API onto the wrong module. ## Where real escapes still come from Almost every reported zip path-escape in Python code comes from **not using `extract()`**. Streaming extraction is a reasonable thing to want — you may need to inspect or transform bytes on the way through — and the shape people reach for is: ```python with zipfile.ZipFile(upload) as zf: for info in zf.infolist(): target = os.path.join(dest, info.filename) # no sanitising happens here os.makedirs(os.path.dirname(target), exist_ok=True) with zf.open(info) as src, open(target, "wb") as out: shutil.copyfileobj(src, out) ``` `os.path.join()` will happily resolve an absolute member name to a path outside `dest`, and `..` components survive. If you must stream, do the containment check yourself: resolve the joined path with `os.path.realpath()` and require that `os.path.commonpath()` of the result and the resolved destination is the destination — the same test `tarfile`'s filter applies internally. Two other details belong in the same loop: refuse a member whose name is empty or is a bare directory you did not expect, and create the parent directory only after the path has been validated, so a rejected member cannot leave stray directories behind. ## What containment does not buy you Name sanitising says nothing about *how much* comes out. `ZipInfo.file_size` is a number in the archive's own headers, written by whoever built the archive; a few hundred kilobytes of deflated zeros expand to hundreds of megabytes, and nesting archives multiplies that. Bounding output is a separate discipline from bounding paths, and neither module does it for you. Nor does it help with what happens *after* extraction. Handing an extracted path to something that opens it by name, or writing into a directory another process scans, reintroduces risk that no extractor can see. Unpack untrusted archives into a fresh temporary directory that nothing else watches, validate the contents there, and only then move what you wanted. ## A checklist for reviewing an extraction call When this code comes past you in review, four questions settle it. Is the destination a directory whose contents nothing else trusts, or is it a working directory a service reads templates and configuration from? Does the code call `ZipFile.extract` or `ZipFile.extractall`, or does it build paths itself? Is there any bound on how much comes out? And does a failure part-way through leave half an archive behind, or does the whole attempt vanish? Only the second of those is answered by the standard library; the other three are yours, and the first is the one most often skipped, because a member landing anywhere *inside* a destination the service later reads is a compromise even though nothing escaped.