Restrict pickle deserialization to safe types (CVE-2025-69872)

[a2811057970]

Summary

Mitigates CVE-2025-69872 by restricting pickle deserialization to a hardcoded allowlist of safe built-in types. Arbitrary objects can no longer be deserialized from cache, preventing code execution via crafted pickle payloads.

Approach

This uses a SafeUnpickler with an allowlist-based find_class override — a fundamentally different approach to #361 (HMAC envelope). The key difference:

• HMAC (Mitigate CVE-2025-69872: HMAC-verified pickle envelope #361): still deserializes arbitrary types once the signature is valid. An attacker with read+write access to the cache directory can read the auto-generated key file and forge payloads.
• Allowlist (this PR): blocks dangerous types regardless of filesystem access. No key management, no env vars, no file creation.

What's allowed

int, float, str, bytes, bytearray, list, dict, tuple, set, frozenset, complex, range, slice, object, bool, None, collections.OrderedDict, collections.defaultdict, collections.deque, datetime.*, decimal.Decimal, fractions.Fraction, uuid.UUID

Everything else raises UnpicklingError on read.

Breaking change

This is intentionally a breaking change (version bumped to 6.0.0). Users caching custom types have two migration paths:

1. Use JSONDisk for JSON-serializable data
2. Subclass Disk and override get()/fetch() with a custom serializer

There is no opt-out by design — an escape hatch would just be cargo-culted by every downstream that hits an error.

Downstream compatibility

UnpicklingError inherits from pickle.UnpicklingError so libraries that catch pickle.PickleError (e.g. dvc-data's translate_pickle_error decorator) handle it gracefully.

Tests

• All 179 existing tests pass unchanged
• 26 new security tests covering: safe type round-trips, exploit blocking (os.system, eval, subprocess, __reduce__), cache integration, no-escape-hatch verification, FanoutCache/Deque/Index
• isort and blue pass

Fixes CVE-2025-69872
Closes #357, #360, #362

[a2811057970]

@grantjenks would appreciate a review when you get a chance. This is a minimal alternative to #361 for CVE-2025-69872 — 150 lines of additive code vs 1000+ lines, with stronger security guarantees (blocks dangerous types even if the attacker has full cache directory access).

[vavsab]

Thanks @a2811057970 for this fix!

While waiting for this to be merged and released, we created a fork with the patch applied.

uv (overrides the transitive dep — no direct dependency needed):

[tool.uv]
override-dependencies = ["diskcache>=6.0.0"]

[tool.uv.sources]
diskcache = { git = "https://github.com/mapped/python-diskcache", tag = "v6.0.2" }

Poetry (only works if diskcache is a direct dependency):

[tool.poetry.dependencies]
diskcache = { git = "https://github.com/mapped/python-diskcache", tag = "v6.0.2" }

Poetry cannot override transitive dependencies by package name — if diskcache is pulled in transitively, use uv instead.

[grantjenks]

Thanks for putting this together. I don’t intend to merge this PR as written.

The central problem is that the change restricts deserialization but not serialization. DiskCache will still successfully write an unsupported object and then fail when the same version tries to read it. That is a particularly surprising failure mode for a cache.

This also breaks existing uses of the Django backend involving functions, model instances, querysets, HttpResponse, and cookies. The linked fork handles those failures by changing the existing tests to expect UnpicklingError; that documents the regression but does not resolve it. Successful testing with one DVC pipeline is useful, but it does not establish general compatibility.

A safe-by-default major release may be reasonable, but it would need at least synchronous rejection of unsupported writes, an explicit trusted-pickle option, honest migration guidance, and complete integration testing. I’m not comfortable adopting a no-opt-out policy or redefining DiskCache’s supported data model through this PR.