Repository navigation
Implement Secure ZIP Extraction for Remote Datasets #1879
Description
Is your feature request related to a problem? Please describe.
Several remote dataset loaders download ZIP archives and extract them directly using zipfile.ZipFile.extractall() without validating archive entries before extraction.
Examples include:
pyrit/datasets/seed_datasets/remote/figstep_dataset.pypyrit/datasets/seed_datasets/remote/vlguard_dataset.py
Current extraction logic relies entirely on Python's built-in ZIP handling and does not explicitly validate extracted paths, file counts, or archive metadata.
Since PyRIT supports Python versions 3.10 through 3.14, adding application-level validation would provide consistent security guarantees across all supported runtimes.
Describe the solution you'd like
Introduce a shared helper for secure ZIP extraction that:
-
Validates archive member paths before extraction.
-
Prevents path traversal attempts.
-
Ensures extracted files remain inside the intended destination directory.
-
Optionally enforces limits on:
- file count,
- individual file size,
- total extracted size.
This helper could then be reused by all dataset downloaders that process remote ZIP archives.
Describe alternatives you've considered, if relevant
The current implementation relies on the protections provided by Python's zipfile module. While modern Python versions include safeguards, explicit validation would provide defense-in-depth and reduce reliance on interpreter-specific behavior.
Additional context
PyRIT currently supports:
requires-python = ">=3.10, <3.15"The same extraction pattern appears in multiple dataset loaders, suggesting that a centralized safe extraction utility would improve maintainability and security across the project.
Activity
romanlutz commentedon Jun 1, 2026
Do you want to handle it yourself Ruslan (@RuslanSemchenko) ?
RuslanSemchenko commentedon Jun 2, 2026
Well, the issue here isn't even about writing improved logic; as far as I'm concerned, we should move away from Python versions 3.10 and 3. 11, since they’ll be EOL very soon, and the best option would be to at least upgrade to 3.12 and, if possible, switch from ZIP to Tar, because if I’m not mistaken, starting with version 3.12, Python added data filtering during the unpacking of Tar archives, and this generally protects against tar slip issues
PEP 706
p.s Just using a ZIP file would require writing a lot of extra code—path checks and so on.
romanlutz commentedon Jun 2, 2026
3.10 will be EOL sometime this year but 3.11 has quite a bit more left. I don't see us dropping it until then.
We don't really have a choice about zip files. They're not provided by us.
francose commentedon Jun 5, 2026
can take this if no one else is on it.
shape i'm thinking:
does that match what you had in mind?
romanlutz commentedon Jun 8, 2026
I didn't open the issue but yes this matches my mental model 🙂 I'll assign it to you _| Y |\| X _84999 (@francose)
marklicata commentedon Aug 27, 2026
Hi Ruslan (@RuslanSemchenko) — Microsoft PM here researching AI red-teaming tool adoption (not on the PyRIT team). You flagged the secure ZIP extraction issue for remote datasets that was accepted by the team. When you came across this gap, were you evaluating PyRIT for use somewhere, and did you end up adopting it or not?
RuslanSemchenko commentedon Sep 3, 2026
To be honest, as far as I can tell, the code was written using AI and outdated syntax—and on top of that, it runs on an old version of Python, which makes adapting it a real pain. Well, most systems have now switched to Python 3.14, and these kinds of problems—exactly the ones that can arise—are ones I believe always need to be addressed. There are many risks and considerations here, such as the “supply chain” and execution risks, as well as the quality and maintainability of the codebase, and, in my opinion, all tools should be, so to speak, rigorous, and I’d rather spend 1–3 days of my own time writing everything by hand, so I’ll know exactly what’s going on and how it works, and the code will be safe in every sense; it may be written a bit unevenly, but I know for sure that this will be better, so I won’t use it right now. For instance, built-in archive extraction filtering (PEP 706) was only introduced in Python 3.12. Running on Python 3.10 without explicit application-level path validation leaves loaders vulnerable to Path Traversal by default