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.

[miraculixx]

The CVE states An attacker with write access to the cache directory can achieve arbitrary code execution when a victim application reads from the cache. While technically true, in practice that is an unlikely attack scenario, unless the attacker already has gained the diskcache user's permissions, in which case there are other means to cause harm. I say this because diskcache uses tempfile.mkdtemp() by default, which uses mode 0700, or makedirs if a non-existing directory is given, using mode 0755 (which could be argued should be 0700, I guess).

python-diskcache/diskcache/core.py

Line 435 in ebfa37c

directory = tempfile.mkdtemp(prefix='diskcache-')

python-diskcache/diskcache/core.py

Line 447 in ebfa37c

os.makedirs(directory, 0o755)

Of course it is conceivable a program provides an existing, multi-user shared directory. In this case, however, responsibility moves to the diskcache user, and the vulnerability is not strictly with diskcache as a library. diskcache's defaults are, it seems to me, secure in regards to the scenario proposed by the CVE.

Proposal
To offer a constructive way forward, diskcache should, by default, sign the payload before pickling it, and verify the signature again before loading it. Of course this means there needs to be a key that is known to the application only, which can be solved by either using an in-memory default key in a single-process application; or by providing one from an external secure source (e.g. keyring) in multi-process applications.

A first rough attempt (consider this pseudo-code to illustrate the proposal, didn't try)

# save
key = secrets.token_bytes(32)  # In-mem default or keyring.get()
    
def signed_dump(obj, file):
    contents = pickle.dumps(obj)  # byte string
    sig = hmac.new(key, contents, hashlib.sha256).digest()
    payload = pickle.dumps((sig, contents))  # sign + contents
    pickle.dump(payload, file)
       
# load
def safe_load(file):
    sig, contents = pickle.load(file)
    if hmac.compare_digest(sig, hmac.new(key, contents hashlib.sha256).digest()):
        obj = pickle.loads(contents)  # this is tamper-safe, i.e. only executed if signature is valid
        return obj
    else:
        raise ValueError("Tampered/invalid cache")