Summary
diskcache (<= 5.6.3, which is the latest release) has a known vulnerability (CVE-2025-69872 / GHSA-w8v5-vhqr-4h9v) related to unsafe pickle deserialization. An attacker with write access to the cache directory can craft a malicious pickle payload that executes arbitrary code when the cache is read.
imf-reader uses diskcache with the default pickle serializer to cache IMF API responses at ~/.cache/imf_reader/weo/.
Upstream status
The diskcache maintainer has not responded to the CVE report (grantjenks/python-diskcache#357) or reviewed the partial mitigation PR (#359). The last commit to diskcache was August 2023, and there are 70+ open issues. The project appears effectively unmaintained for security purposes.
There is no patched version of diskcache available.
Practical risk
The practical risk for imf-reader is low — the cache is in the user's home directory, the data comes from a trusted public API, and an attacker with home directory write access likely has more direct attack vectors. However, this CVE causes security scanners to flag any project that transitively depends on diskcache, which creates compliance issues for downstream consumers like pydeflate.
Possible approaches
-
Switch to JSONDisk serializer for codelist/dict caching (JSON-safe data). This is what Fedora's downstream patch does. DataFrame caching would need an alternative approach (e.g., parquet via pyarrow).
-
Make diskcache an optional dependency — this is what projects like FastMCP and Instructor have done. Caching would only be available when the user explicitly installs diskcache.
-
Replace diskcache with an alternative — e.g., joblib (common in data science), dogpile.cache, or a simple SQLite + JSON/parquet approach.
-
Pin and document the accepted risk until upstream resolves the issue.
References
Summary
diskcache(<= 5.6.3, which is the latest release) has a known vulnerability (CVE-2025-69872 / GHSA-w8v5-vhqr-4h9v) related to unsafe pickle deserialization. An attacker with write access to the cache directory can craft a malicious pickle payload that executes arbitrary code when the cache is read.imf-readerusesdiskcachewith the default pickle serializer to cache IMF API responses at~/.cache/imf_reader/weo/.Upstream status
The
diskcachemaintainer has not responded to the CVE report (grantjenks/python-diskcache#357) or reviewed the partial mitigation PR (#359). The last commit todiskcachewas August 2023, and there are 70+ open issues. The project appears effectively unmaintained for security purposes.There is no patched version of
diskcacheavailable.Practical risk
The practical risk for
imf-readeris low — the cache is in the user's home directory, the data comes from a trusted public API, and an attacker with home directory write access likely has more direct attack vectors. However, this CVE causes security scanners to flag any project that transitively depends ondiskcache, which creates compliance issues for downstream consumers likepydeflate.Possible approaches
Switch to
JSONDiskserializer for codelist/dict caching (JSON-safe data). This is what Fedora's downstream patch does. DataFrame caching would need an alternative approach (e.g., parquet via pyarrow).Make
diskcachean optional dependency — this is what projects like FastMCP and Instructor have done. Caching would only be available when the user explicitly installsdiskcache.Replace
diskcachewith an alternative — e.g.,joblib(common in data science),dogpile.cache, or a simple SQLite + JSON/parquet approach.Pin and document the accepted risk until upstream resolves the issue.
References