GeezerVison

@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).

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.

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.

Thank you for the safe-unpickler fix.

We consume DiskCache transitively and are currently blocked by
CVE-2025-69872 / GHSA-w8v5-vhqr-4h9v in dependency-security gates.

Could a maintainer review and merge this PR, then publish a release containing
the fix? A released version is needed for downstream users to clear the OSV
advisory. I can test a release candidate if helpful.