CVE-2025-1889
Mmaitre314 Picklescan ≤ 0.0.22
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2025-1889 is a medium-severity Reliance on File Name or Extension of Externally-Supplied File (CWE-646) vulnerability in Mmaitre314 Picklescan. Its CVSS base score is 5.3 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Double File Extension (T1036.007); ranked at the 31th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-1889 is a critical vulnerability (CVSS 9.8, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) affecting picklescan versions prior to 0.0.22. Picklescan is a vulnerability scanning tool that detects unsafe pickle usage in Python files, but it only considers files with standard pickle extensions (such as .pkl or .pickle) within its scan scope. This limitation allows malicious pickle files with non-standard extensions to evade detection, leading to false negatives where unsafe files appear secure. The issue is linked to CWE-646 (Reliance on File Name or Extension) and NVD-CWE-noinfo.
An attacker can exploit this vulnerability by crafting a malicious Python model or package that incorporates a dangerous pickle file renamed with a non-standard extension. A security practitioner or developer using the vulnerable picklescan to scan a repository or artifact containing this malicious file would receive a clean bill of health, potentially leading to the file being trusted and loaded. Upon deserialization, the pickle file could execute arbitrary code, resulting in high confidentiality, integrity, and availability impacts remotely with no authentication or user interaction required.
The GitHub security advisory (GHSA-655q-fx9r-782v) and Sonatype advisory detail mitigation steps, primarily recommending an upgrade to picklescan 0.0.22 or later, which expands the scan scope to include non-standard pickle extensions and prevents such bypasses. Practitioners should rescan existing models or dependencies after patching to identify previously missed threats.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-5523
Vulnerability Data
picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle and include a malicious pickle file with a non-standard file extension. Because the malicious…
more
pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Requires validation of information inputs, which structurally stops reliance on untrusted file names or extensions by forcing content-based checks.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require content-based validation instead of trusting file extensions for externally supplied files.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect the weakness, but the control does not guarantee its elimination.
Restricting software installation can limit dangerous file types but does not enforce content-based validation.
Web filtering can block risky file extensions but does not address server-side file handling logic.
Secure SDLC requires proper file-type validation, directly mitigating reliance on untrusted names or extensions.
Application security requirements can mandate content inspection, but the control itself does not prescribe the technique.
Secure architecture principles encourage safe file handling, yet the control is broader than this specific weakness.