GeezerVison is showing github.com — docs: Zipfile contains a 13-years outdated warning regarding path sanitization · Issue #157339 · python/cpython
docs: Zipfile contains a 13-years outdated warning regarding path sanitization #157339DescriptionDocumentation
The extract/extractall documentation contains a warning that became outdated 13 years ago:
https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.extractall
"Warning: Never extract archives from untrusted sources without prior inspection. It is possible that files are created outside of path, for example, members that have absolute filenames or filenames with “..” components. This module attempts to prevent that. See extract() note."
This incorrect and completely outdated comment should have been deleted when the malicious zip sanitization was added to Python 13 years ago, in February 2013:
b47acbf
Here's the official Python code:
https://github.com/python/cpython/blob/main/Lib/zipfile/__init__.py#L2467
Both extract() and extractall() use _extract_member, which performs complete sanitizing:
# 1. Strips leading slashes (/), drive letters (C:), and UNC paths (\\server\share)
drive, root, arcname = os.path.splitroot(arcname)
...
# 2. Defines invalid parts: empty strings, current directory (.), and parent directory (..)
invalid_path_parts = ('', os.path.curdir, os.path.pardir)
# 3. Filters out any occurrences of '.' and '..'
arcname = os.path.sep.join(x for x in arcname.split(os.path.sep)
if x not in invalid_path_parts)And even the original Zip Slip author said that Python is not vulnerable:
https://security.snyk.io/research/zip-slip-vulnerability
"We also vetted the Ruby and Python ecosystems and couldn’t find any vulnerable code snippets or libraries. In fact, Python libraries were vulnerable until fixed in 2014. Ruby has a number of existing vulnerabilities that have been fixed in previous versions here , here and here."
(He's wrong about 2014; Python added the malicious Zip path sanitization in February 2013.) Activitygvanrossum commented on Sep 11, 2026 Have there not been any CVEs against this validation code? Arcitec commented on Sep 11, 2026 @gvanrossum Not that I can find.
cve python zipfile extract finds only these things:
- python-libarchive: A totally separate third-party library (unrelated).
- gramps-webapi: A self-reported "CVE" which was not a CVE at all and was based on the person misunderstanding the exact warning I am recommending that Python removes. The author thought Python does not remove ".." from file paths. Python has sanitized that exact thing (and everything else) since February 2013.
- praisonai: Another self-reported "CVE" which is absolute nonsense. In this case, it clearly looks like an AI-generated nonsense "CVE". It gives a code example for how to exploit Python. But if the author had bothered to run the code at all, they would have seen that Python doesn't do what the "CVE" claims. All paths are fully sanitized. The crafted zip file with a
../../../../../../../tmp/zip_slip_pwned.txt path, exactly as described in that "CVE", extracts as tmp/zip_slip_pwned.txt thanks to Python's sanitization (not /tmp/zip_slip_pwned.txt as the "CVE" falsely claims).
- safe_unzip: A completely AI-hallucinated library which claims to "fix the Zip Slip vulnerability" in Python. Except there's no such vulnerability. It shows an exploit that doesn't work at all on Python. It also hallucinates that Python's Zipfile
extractall("/var/uploads", filter="data") has a filter parameter, which isn't true and is only relevant for the tarfile library (which was indeed vulnerable by default until Python 3.14, when "filter=data" became default). This AI-hallucinated library is a direct effect of AIs reading the incorrect, outdated documentation for Python's zipfile library.
- People's attempts to "patch the (non-existent) ZipSlip vulnerability in Python" are all over the internet, which is all due to people seeing the outdated, very misleading Python documentation/warning. For example, fix: prevent Zip Slip path traversal in ZIP extraction volcengine/OpenViking#879.
Most importantly, Zip Slip's author was never able to exploit Python, as I quoted in the original message. Arcitec commented on Sep 11, 2026 @gvanrossum Let's break down Python's current, scary warning step by step:
https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.extractall
"Warning: Never extract archives from untrusted sources without prior inspection."
Only scary if you're doing something bad with the extracted files afterwards, such as immediately trusting and running code that was extracted. This warning is just common sense and is not necessary.
"It is possible that files are created outside of path, for example, members that have absolute filenames or filenames with “..” components."
False since February 2013 (b47acbf). Python removes:
- Leading slashes (/), drive letters (C:), and UNC paths (\server\share). So
/foo or C:\foo becomes foo.
- Path components that are just empty strings, current directory (.), and parent directory (..). So
foo/../bar becomes foo/bar.
- All of this has robust testing in
test_extract_hackers_arcnames_common_cases, test_extract_hackers_arcnames_windows_only and test_extract_hackers_arcnames_posix_only at
|
def test_extract_hackers_arcnames_common_cases(self): |
(and these tests were added in 2013 along with the original patch).
- The tests are robust enough to verify that Python even sanitizes mixed scenarios where a Zip has malicious, mixed path separators (both
\ and / at the same time).
- So claiming that extracted paths can contain
/ or .. is plain false.
"This module attempts to prevent that. See extract() note."
It doesn't "attempt" to prevent that. It prevents it. As explained in my previous comments, and seen in Python's own test suite, Python's zipfile library completely sanitizes all of those exploits.
Zip Slip's author (Snyk) was totally unable to exploit Python. gvanrossum commented on Sep 11, 2026 Are you using AI to help you write these comments? They sound unnecessarily aggressive. Try to tone it down. We get the point. Reacted by Stan Ulbrych Reacted by Uttam Bhadauriya Arcitec commented on Sep 11, 2026 @gvanrossum No. Sigh. I hate that AI was trained on people who write carefully and methodically. This is all by hand. I've had this writing style for the past 30 years. And sorry for coming across as aggressive. I am autistic. gvanrossum commented on Sep 11, 2026 My apologies. I suspect that most LLMs are trained on many different styles and personalities. I'm a bit sensitive to this because (like all open source projects) we get a lot of AI-slop issues, and I recently dealt with an overly aggressive and accusatory AI that caused some upheaval.
I'm also suspicious of claims that, just because we check for a certain type of malicious attack vector, we are now secure: we do see CVEs against Python (e.g. for tarfile, which has similar issues) where an attacker has found a hole in the checking code. This is common enough that I wouldn't mind keeping that warning forever -- after all, it does say that the module attempts to prevent that.
I'll leave it to the current maintainers of zipfile to decide whether to keep the warning, tone it down, or remove it. Reacted by Johnny Arcitec Arcitec commented on Sep 12, 2026 @gvanrossum Yeah, I have seen how much nonsense extra work AIs create for projects, and have been on the receiving end of AI slop too, so you have my full sympathies.
Speaking of AI. When searching for CVEs, there were so many projects that had hallucinated that Python's zipfile is vulnerable and that it "doesn't sanitize / or .. at all". They had full examples of "vulnerable Zip files and how they escape the target extraction path", except none of them had tested their own code, since Python completely sanitizes their own "vulnerability reproduction examples".
This confusion is caused by that documentation warning. It misleads both humans and AIs, since it essentially claims that Python does no path sanitization at all. That's because the current warning text is copied verbatim from what Python's doc used to say way back before the sanitization was even added, back when it really didn't sanitize.
You can see that the whole warning was originally removed in the sanitization commit:
b47acbf
It was later re-added verbatim (including the old "It's possible that files will be created outside of path"), with a new "This module attempts to prevent that." at the end. Which is vague and creates uncertainty. The warning needs some rewording (if not outright removal), since it's causing confusion.
When looking at Python's code and test suite, it's clear that the sanitization is very strong and well-tested. It eliminates all absolute leading paths and all ".." path components. Zip Slip's author would have salivated at including Python in the list of vulnerable languages when that whole situation blew up in 2018. But instead, it was deemed clear. And the zipfile test suite is the strongest proof that it's all clear:
|
def test_sanitize_windows_name(self): |
|
san = zipfile.ZipFile._sanitize_windows_name |
|
# Passing pathsep in allows this test to work regardless of platform. |
|
self.assertEqual(san(r',,?,C:,foo,bar/z', ','), r'_,C_,foo,bar/z') |
|
self.assertEqual(san(r'a\b,c<d>e|f"g?h*i', ','), r'a\b,c_d_e_f_g_h_i') |
|
self.assertEqual(san('../../foo../../ba..r', '/'), r'foo/ba..r') |
|
self.assertEqual(san(' / /foo / /ba r', '/'), r'foo/ba r') |
|
self.assertEqual(san(' . /. /foo ./ . /. ./ba .r', '/'), r'foo/ba .r') |
|
|
|
def test_extract_hackers_arcnames_common_cases(self): |
|
common_hacknames = [ |
|
('../foo/bar', 'foo/bar'), |
|
('foo/../bar', 'foo/bar'), |
|
('foo/../../bar', 'foo/bar'), |
|
('foo/bar/..', 'foo/bar'), |
|
('./../foo/bar', 'foo/bar'), |
|
('/foo/bar', 'foo/bar'), |
|
('/foo/../bar', 'foo/bar'), |
|
('/foo/../../bar', 'foo/bar'), |
|
] |
|
self._test_extract_hackers_arcnames(common_hacknames) |
|
|
|
@unittest.skipIf(os.path.sep != '\\', 'Requires \\ as path separator.') |
|
def test_extract_hackers_arcnames_windows_only(self): |
|
"""Test combination of path fixing and windows name sanitization.""" |
|
windows_hacknames = [ |
|
(r'..\foo\bar', 'foo/bar'), |
|
(r'..\/foo\/bar', 'foo/bar'), |
|
(r'foo/\..\/bar', 'foo/bar'), |
|
(r'foo\/../\bar', 'foo/bar'), |
|
(r'C:foo/bar', 'foo/bar'), |
|
(r'C:/foo/bar', 'foo/bar'), |
|
(r'C://foo/bar', 'foo/bar'), |
|
(r'C:\foo\bar', 'foo/bar'), |
|
(r'//conky/mountpoint/foo/bar', 'foo/bar'), |
|
(r'\\conky\mountpoint\foo\bar', 'foo/bar'), |
|
(r'///conky/mountpoint/foo/bar', 'mountpoint/foo/bar'), |
|
(r'\\\conky\mountpoint\foo\bar', 'mountpoint/foo/bar'), |
|
(r'//conky//mountpoint/foo/bar', 'mountpoint/foo/bar'), |
|
(r'\\conky\\mountpoint\foo\bar', 'mountpoint/foo/bar'), |
|
(r'//?/C:/foo/bar', 'foo/bar'), |
|
(r'\\?\C:\foo\bar', 'foo/bar'), |
|
(r'C:/../C:/foo/bar', 'C_/foo/bar'), |
|
(r'a:b\c<d>e|f"g?h*i', 'b/c_d_e_f_g_h_i'), |
|
('../../foo../../ba..r', 'foo/ba..r'), |
|
] |
|
self._test_extract_hackers_arcnames(windows_hacknames) |
|
|
|
@unittest.skipIf(os.path.sep != '/', r'Requires / as path separator.') |
|
def test_extract_hackers_arcnames_posix_only(self): |
|
posix_hacknames = [ |
|
('//foo/bar', 'foo/bar'), |
|
('../../foo../../ba..r', 'foo../ba..r'), |
|
(r'foo/..\bar', r'foo/..\bar'), |
|
] |
|
self._test_extract_hackers_arcnames(posix_hacknames) |
The test suite actually creates vulnerable zip files, runs them through the extractor, and verifies that every path was sanitized. It's beautiful.
I also thought about whether there could be new ways to escape a zip file. But Zip Slip came out in 2018 (and the issue was known before then), and so many eyes and minds have tried all imaginable ways to escape from Zip files since then, especially when various languages spent time hardening their Zip libraries against the attack in 2018. And no security researchers came up with any other attacks. Python protects against all known methods.
A new and improved warning might at least say something about how Python performs strong path sanitization in both extract() and extractall(), and that path traversal is impossible with all known Zip path manipulation methods (the test suite guarantees that). But that there might still be some new, undiscovered method of Zip escape in the future (on a personal note, it's very unlikely considering how deeply the topic has been researched).
And regarding the tarfile library, that was indeed vulnerable for a long time (and is vulnerable by default until Python 3.14, where the "data" filter is finally applied by default). Its warning is also clear and well-written and explains how to apply the filter. :) StanFromIreland commented on Sep 12, 2026 Just a suggestion, when searching for CVEs for CPython, it'll probably be easier to grep our database, rather than Googling for them. Reacted by Johnny Arcitec Arcitec commented on Sep 13, 2026 @StanFromIreland Thanks, I went through all results there and nothing is related to malicious path handling.
The CVEs were standard stuff like "zip bombs" (a tiny zip that refers to the same block over and over to expand to a huge file). StanFromIreland commented on Sep 13, 2026 Note that this note was recently updated in ba0aca3. I don't consider it incorrect, it notes the possibility of such escapes and refers to the note on ZipFile.extract which covers the normalisation we do do. The note also serves an important purpose, it notes the general security guideline for ZipFile.extractall.
MetadataMetadataStatusShow more project fields StatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|