Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI

GHSA-mjqp-26hc-grxg

HIGH

Picklescan: ZIP archive scan bypass is possible through non-exhaustive Cyclic Redundancy Check

Also known asCVE-2025-10156PYSEC-2025-152
Published
Sep 10, 2025
Updated
Jun 6, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
1.4%probability of exploitation in next 30 days
Lower Risk70th percentile+0.37%
0.00%0.64%1.29%1.93%0.3%1.4%Dec 25Apr 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected
🐍picklescan

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Picklescan's ability to scan ZIP archives for malicious pickle files is compromised when the archive contains a file with a bad Cyclic Redundancy Check (CRC). Instead of attempting to scan the files within the archive, whatever the CRC is, Picklescan fails in error and returns no results. This allows attackers to potentially hide malicious pickle payloads within ZIP archives that PyTorch might still be able to load (as PyTorch often disables CRC checks).

Details

Picklescan likely utilizes Python's built-in zipfile module to handle ZIP archives. When zipfile encounters a file within an archive that has a mismatch between the declared CRC and the calculated CRC, it can raise an exception (e.g., BadZipFile or a related error). It appears that Picklescan does not try to scan the files whatever the CRC is. This behavior contrasts with PyTorch's model loading capabilities, which in many cases might bypass CRC checks for ZIP archives - whatever the configuration is. This discrepancy creates a blind spot where a malicious model packaged in a ZIP with a bad CRC could be loaded by PyTorch while being completely missed by Picklescan.

PoC

  1. Download an existing Pytorch model with a bad CRC

wget <https://huggingface.co/jinaai/jina-embeddings-v2-base-en/resolve/main/pytorch_model.bin?download=true> -O pytorch_model.bin

  1. Attempt to scan the corrupted ZIP file with PickleScan:
# Assuming you have Picklescan installed and in your PATH
picklescan -p pytorch_model.bin

Screenshot 2025-06-29 at 13 52 07 Observed Result: Picklescan returns no results and presents an error message indicating a problem with the ZIP file, but it doesn’t attempt to scan any potentially valid pickle files within the archive.

Expected Result: Picklescan should either:

  • Attempt to extract and scan other valid files within the ZIP archive, even if some have CRC errors.
  • Report a warning indicating that the ZIP archive has CRC errors and might be incomplete or corrupted, but still attempt to scan any accessible content.

Impact

Severity: High Affected Users: Any organization or individual using Picklescan to analyze PyTorch models or other files distributed as ZIP archives for malicious pickle content. Impact Details: Attackers can craft malicious PyTorch models containing embedded pickle payloads, package them into ZIP archives, and intentionally introduce CRC errors. This would cause Picklescan to fail to analyze the archive, while PyTorch is still able to load the model (depending on its configuration regarding CRC checks). This creates a significant vulnerability where malicious code can be distributed and potentially executed without detection by Picklescan. Ex: Picklescan on HuggingFace goes into error (https://huggingface.co/jinaai/jina-embeddings-v2-base-en/tree/main) Screenshot 2025-06-29 at 13 55 58

Recommendations: Picklescan should not fail on Bad CRC check, especially if Pytorch is not checking CRC. Relaxed Zipfile is perfect to fix this issue:

--- picklescan/src/picklescan/relaxed_zipfile.py
+++ picklescan/src/picklescan/relaxed_zipfile.py
@@ class RelaxedZipFile(zipfile.ZipFile):
         try:
             # Skip the file header:
             fheader = zef_file.read(sizeFileHeader)
             if len(fheader) != sizeFileHeader:
                 raise zipfile.BadZipFile("Truncated file header")

             fheader = struct.unpack(structFileHeader, fheader)
             if fheader[_FH_SIGNATURE] != stringFileHeader:
                 raise zipfile.BadZipFile("Bad magic number for file header")

             zef_file.read(fheader[_FH_FILENAME_LENGTH])
             if fheader[_FH_EXTRA_FIELD_LENGTH]:
                 zef_file.read(fheader[_FH_EXTRA_FIELD_LENGTH])

-            return zipfile.ZipExtFile(zef_file, mode, zinfo, pwd, True)
+
+            # Create the ZipExtFile and disable CRC check
+            ext_file = zipfile.ZipExtFile(zef_file, mode, zinfo, pwd)
+            # Monkey-patch to skip CRC validation
+            ext_file._expected_crc = None
+            return ext_file

         except BaseException:
             zef_file.close()
             raise

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIpicklescanall versions0.0.31

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for picklescan. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update picklescan to 0.0.31 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mjqp-26hc-grxg is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-mjqp-26hc-grxg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-mjqp-26hc-grxg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary Picklescan's ability to scan ZIP archives for malicious pickle files is compromised when the archive contains a file with a bad Cyclic Redundancy Check (CRC). Instead of attempting to scan the files within the archive, whatever the CRC is, Picklescan fails in error and returns no results. This allows attackers to potentially hide malicious pickle payloads within ZIP archives that PyTorch might still be able to load (as PyTorch often disables CRC checks). ### Details Picklescan likely utilizes Python's built-in zipfile module to handle ZIP archives. When zipfile encounters a file
O3 Security · Impact-Aware SCA

Is GHSA-mjqp-26hc-grxg in your dependencies?

O3 detects GHSA-mjqp-26hc-grxg across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-mjqp-26hc-grxg: picklescan Malicious Code / Backdoor (High… | O3 Security