Changes between Version 33 and Version 34 of SecurityTeam

Timestamp:

Jun 24, 2026, 1:43:45 PM (24 hours ago)

Author:

Natalia Bidart

Comment:

Added Pickle deserialization canned response.

SecurityTeam

@@ -211 +211 @@
 Kind regards, The Django Security Team.
 
+=== Unauthenticated cache purge/Pickle deserialization ===
+
+Hello,
+
+Thank you for your report.
+
+After review, we do not consider this a security vulnerability. Django's cache backends treat the cache store as a trusted component, equivalent to the database. If an attacker is able to write to your cache backend (whether Memcached, Redis, or the filesystem), your application is already operating outside of its assumed trust boundary, and Django's security guarantees no longer apply. This is explicitly documented [0].
+
+Django makes a deliberate choice not to harden against a compromised cache layer, for the same reason it does not harden against a compromised database layer: doing so is the operator's responsibility, and some underlying drivers use pickle internally in ways that would make blanket hardening impractical.
+
+If you're interested in optional signing as a defense-in-depth measure, that discussion is ongoing publicly [1] and has an solved ticket needing contribution [2].
+
+Kind regards, the Django Security Team.
+
+[0] https://docs.djangoproject.com/en/dev/topics/cache/#:~:text=An%20attacker%20who%20gains%20access%20to%20the%20cache%20file
+
+[1] https://forum.djangoproject.com/t/adding-optional-signing-of-cache-data/41820
+
+[2] https://code.djangoproject.com/ticket/35905
+
 === Confusion with YANGO (usually sent in Spanish) ===
 
@@ -221 +241 @@
 Saludos.
 
-=== Unauthenticated cache purge ===
-
-(This is a known behavior and we've previously disregarded such reports, needs a skeleton response.)
-
 == Duplicated (unreleased) report ==