Vulnerability CVE-2025-69872

[benglewis]

GHSA-w8v5-vhqr-4h9v
https://nvd.nist.gov/vuln/detail/CVE-2025-69872
https://github.com/EthanKim88/ethan-cve-disclosures/blob/main/CVE-2025-69872-DiskCache-Pickle-Deserialization.md

This is a bit of a blocker for a lot of us who are scanning for vulnerabilities all of the time

[onnokort]

So... at the risk of poking a hornet's nest: What is the exact issue here? Isn't this basically just a "documentation bug"?

(I am just a user of diskcache who happened to stumble upon this.)

[kkirsche]

So... at the risk of poking a hornet's nest: What is the exact issue here? Isn't this basically just a "documentation bug"?

(I am just a user of diskcache who happened to stumble upon this.)

No, it’s not just a documentation bug — but I understand why it might look that way at first glance.

The “pickle is unsafe with untrusted data” thing is well-known, and diskcache does mention you can swap serializers. But there’s a meaningful difference between “a library happens to use pickle internally” and “a library that persists data to a shared, world-readable disk location uses pickle deserialization by default with no warnings at the point of use.”

The core issue is the default attack surface: diskcache writes pickled objects to disk (often /tmp or a predictable cache directory). If an attacker has write access to that cache directory — which is a realistic scenario in shared hosting, multi-tenant environments, container misconfigs, or local privilege escalation — they can replace cached data with a malicious pickle payload. The next time the application reads from the cache, it gets arbitrary code execution. No user interaction required beyond normal cache reads.

So while it’s true that Python’s own docs say “don’t unpickle untrusted data,” the CVE is calling out that diskcache by default creates a trust boundary (local filesystem) that’s weaker than most users assume, and doesn’t make the risk obvious. It’s the difference between “the docs say don’t do this” and “the library’s default config creates a concrete, exploitable attack path.”

That said — reasonable people do disagree about whether this class of issue deserves a CVE vs. a strongly-worded doc update. It sits in a gray area. But from a security assessment perspective, “unsafe default that leads to RCE” generally clears the bar.

[onnokort]

That said — reasonable people do disagree about whether this class of issue deserves a CVE vs. a strongly-worded doc update. It sits in a gray area. But from a security assessment perspective, “unsafe default that leads to RCE” generally clears the bar.

Yes. diskcache uses tempfile.mkdtemp(..) by default and the documentation states:

Creates a temporary directory in the most secure manner possible. There are no race conditions in the directory’s creation. The directory is readable, writable, and searchable only by the creating user ID.

[kkirsche]

Yes. diskcache uses tempfile.mkdtemp(..) by default and the documentation states:

Creates a temporary directory in the most secure manner possible. There are no race conditions in the directory’s creation. The directory is readable, writable, and searchable only by the creating user ID.

That’s a fair point — mkdtemp with 0700 permissions does meaningfully narrow the attack surface in standard single-user deployments, and I don’t want to dismiss that.

For me, what keeps it high severity is primarily how common root-in-containers still is — when everything runs as the same UID, the directory permissions stop being a meaningful boundary. There are other scenarios too (shared service accounts, cache directories intentionally set to shared paths for inter-process use, lateral movement from an already-compromised process), but the container case alone is widespread enough to matter.

The underlying concern is that pickle deserialization runs without any integrity verification — no signing, no HMAC — so filesystem permissions end up being the sole trust boundary for something that gives you RCE if it breaks down. That gap between “what could happen” and “what’s protecting you” is what pushes it past a documentation issue for me, but I also recognize this is exactly the kind of thing where the line between “unsafe default” and “known property of a dependency” is genuinely debatable.

At the end of the day, the most important thing is understanding what pickle deserialization actually does under the hood and evaluating whether your specific deployment model keeps that trust boundary intact. For plenty of use cases it absolutely does — which is exactly why it’s the kind of CVE that won’t matter to everyone equally.