https://spaceraccoon.github.io/vulnerability-spoiler-alert Vulnerability alerts for django/django en-us Tue, 01 Sep 2026 14:23:07 GMT https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/378 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/378 Thu, 06 Aug 2026 09:49:39 GMT When using Django admin's 'save as new' functionality, inline formsets for related models where the user lacks add permission (but has view permission) could be rendered as editable/populated forms upon a validation error re-render, because the total/initial form counts were not cleared before instantiating the formset. This allowed a user without add permission on the inline model to potentially submit and persist changes to inline objects that they should only be able to view, effectively bypassing the permission check enforced elsewhere in the admin. medium confirmed CVE-2026-15920 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/366 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/366 Tue, 04 Aug 2026 16:01:44 GMT GeoDjango spatial lookups optimistically parsed lookup values as GDALRaster before falling back to GEOSGeometry parsing. Because GDALRaster's constructor could interact with GDAL virtual filesystem drivers regardless of the write=False flag, a malicious string or dict passed into a spatial lookup (e.g., via the Django admin's changelist filtering, which allows staff users to submit arbitrary lookups) could cause the server to write files to disk or issue network requests to attacker-controlled URLs. The patch blocks strings and dicts from being treated as raster input in lookup contexts unless explicitly wrapped in GDALRaster, closing the SSRF/file-write vector while preserving normal model field assignment behavior. Patch landed 6 hours 41 minutes before CVE-2026-15307 was published. high confirmed CVE-2026-15307 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/365 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/365 Tue, 04 Aug 2026 16:01:13 GMT The check_for_language() function used an lru_cache with maxsize=1000, but did not limit the length of the lang_code strings used as cache keys. An attacker could submit many distinct, very long language codes (e.g., via the set_language() view's POST data), causing up to 1000 large strings to be retained in memory as cache keys, consuming excessive process memory. The patch adds a length check (max 500 characters) before the cached lookup, so long codes are rejected without being cached. Patch landed 6 hours 41 minutes before CVE-2026-15337 was published. low confirmed CVE-2026-15337 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/364 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/364 Tue, 04 Aug 2026 16:01:02 GMT Before this patch, GEOSGeometry parsing (from WKT or WKB) had no limit on the depth or number of nested GEOMETRYCOLLECTION elements. Because GEOS parses these recursively, a maliciously crafted input with deeply nested geometry collections could exhaust the stack or memory and trigger a fatal error/crash in GEOS, effectively causing a denial of service in any application that accepts user-supplied geometry data (e.g., via GeometryField model/form fields). The patch introduces a `max_geom_collections` parameter, forwarded through GEOSGeometry, model fields, and form fields, to cap the depth (for WKT) or total count (for WKB) of nested collections before they reach the GEOS library. Patch landed 6 hours 41 minutes before CVE-2026-15830 was published. high confirmed CVE-2026-15830 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/363 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/363 Tue, 04 Aug 2026 16:00:47 GMT The Django admin's display_for_field() rendered URLField values as clickable <a href> links without validating the URL scheme. A stored value using a dangerous scheme like javascript: or data: would be rendered as a clickable link, and clicking it would execute arbitrary script in the authenticated admin session (staff user context). Patch landed 6 hours 41 minutes before CVE-2026-15920 was published. medium confirmed CVE-2026-15920 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/349 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/349 Thu, 23 Jul 2026 13:30:02 GMT inspectdb generates a Python models.py file by writing raw table names and exception messages directly into comment lines without escaping. If a table name or an introspection error message contains newline characters, the unescaped output breaks out of the '#' comment prefix and injects arbitrary attacker-controlled lines into the generated source file, which is later imported/executed as Python code. Patch landed 12 days 5 hours 36 minutes before CVE-2026-15307 was published. medium confirmed CVE-2026-15307 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/315 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/315 Tue, 07 Jul 2026 14:17:36 GMT DomainNameValidator's regex used `$` instead of `\\Z` as the end anchor, which in Python regex matches before a trailing newline. This allowed strings like 'example.com\\n' to pass validation as a valid domain name, potentially enabling HTTP header/CRLF injection if such validated values were later embedded into HTTP headers or other newline-sensitive contexts outside Django's form fields. Patch landed 12 hours 2 minutes before CVE-2026-53878 was published. low confirmed CVE-2026-53878 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/316 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/316 Tue, 07 Jul 2026 14:17:48 GMT When constructing a GDALRaster from a bytes object, the code used sys.getsizeof() to determine the buffer size, which includes CPython's PyBytesObject overhead (~32-49 bytes) rather than the actual data length. This caused GDAL to read past the end of the allocated buffer into adjacent heap memory when accessing the vsi_buffer property, potentially disclosing sensitive heap memory contents or causing a crash. Patch landed 12 hours 2 minutes before CVE-2026-53877 was published. low confirmed CVE-2026-53877 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/317 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/317 Tue, 07 Jul 2026 14:18:10 GMT UpdateCacheMiddleware only skipped caching Set-Cookie responses varying on Cookie when the incoming request had zero cookies, so a request carrying any unrelated cookie (e.g., a language preference) bypassed the protection. This allowed a response that issues a new session or CSRF cookie to be stored in Django's shared cache and served to other users, leaking session cookies via a shared cache hit. The patch removes the 'no cookies at all' condition, always skipping caching when a response sets a cookie and varies on Cookie. Patch landed 12 hours 2 minutes before CVE-2026-48588 was published. low confirmed CVE-2026-48588 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/298 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/298 Wed, 24 Jun 2026 14:53:10 GMT The `_generate_cache_key` function in Django's cache framework concatenated HTTP header values without any delimiter when building the cache key hash. This allowed two requests with different header values to produce the same cache key if the values concatenated to the same string (e.g., headers 'EU' and '' vs '' and 'EU'). The patch fixes this by using netstring encoding (length-prefixed with trailing comma) for each header value, ensuring unique encodings for distinct value combinations. Patch landed 13 days 1 hour 32 minutes before CVE-2026-53878 was published. medium confirmed CVE-2026-53878 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/297 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/297 Wed, 24 Jun 2026 14:52:53 GMT The template fragment cache key generation used a simple `:` delimiter between vary-on arguments without encoding the length of each argument, allowing cache key collisions between different argument combinations. For example, vary_on=\['a:b','c'\] and vary_on=\['a','b:c'\] would produce the same MD5 hash, potentially causing one user's cached content to be served to another user with different cache parameters. medium verified https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/289 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/289 Fri, 19 Jun 2026 17:01:48 GMT Django's UpdateCacheMiddleware failed to recognize qualified Cache-Control directives (e.g., `Cache-Control: private="Set-Cookie"`) as restrictions on caching. The code used exact token matching against the full directive string, so `private="Set-Cookie"` would not match the string `private`, causing the response to be stored in a shared cache even though it was marked private. The patch introduces a `split_directive_names()` helper that strips the qualified value portion before comparison. medium confirmed CVE-2026-35193 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/265 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/265 Tue, 16 Jun 2026 23:27:58 GMT Before the patch, passing a 'Bcc' key in the `extra_headers` argument of `EmailMessage` would cause the BCC addresses to be serialized directly into the email message headers, making them visible to all recipients. The `from`, `to`, `cc`, and `reply-to` headers were explicitly excluded from being written via `extra_headers`, but `bcc` was not, allowing it to leak into the message. The patch raises a `ValueError` when `Bcc` is found in `extra_headers`, directing users to use the `bcc` argument instead. Patch landed 48 days 19 hours 35 minutes before CVE-2026-15307 was published. medium confirmed CVE-2026-15307 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/254 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/254 Tue, 09 Jun 2026 16:38:30 GMT When Django's `startproject` or `startapp` command downloads a template archive from a URL, the Content-Disposition header's filename was used directly with `os.path.join()` to construct a path within a temp directory. An attacker-controlled server could return a filename like `/nonexistent/../../etc/passwd` or an absolute path, causing the file to be written outside the intended temporary directory. The fix replaces `os.path.join()` with `safe_join()`, which raises `SuspiciousFileOperation` if the resulting path escapes the base directory. high verified https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/253 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/253 Tue, 09 Jun 2026 15:43:53 GMT The UpdateCacheMiddleware used a substring check (`directive in cache_control`) to detect Cache-Control directives like 'private', 'no-cache', 'no-store', and 'public'. This meant that an extension directive like 'myprivate' or 'nopublic' would be falsely matched, causing responses that should be cached to not be cached, or causing Authorization-based Vary headers to be incorrectly omitted. More critically, the inverse case for 'public' means that a response with a custom directive containing 'public' as a substring would skip the Authorization vary header, potentially serving a user-specific cached response to other users. The fix replaces substring matching with exact token matching using `split_header_value`. medium confirmed CVE-2026-35193 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/239 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/239 Wed, 03 Jun 2026 17:53:22 GMT Django's signed cookie salt derivation historically used `cookie_name + salt` (concatenation), which is ambiguous: a cookie named 'a' with salt 'bc' produces the same salt string as a cookie named 'ab' with salt 'c'. This means a valid signed cookie for one (name, salt) pair could be submitted as a valid cookie for a different (name, salt) pair, allowing an attacker to reuse a legitimately obtained signed cookie value in an unintended context. The patch changes the default of SIGNED_COOKIE_LEGACY_SALT_FALLBACK from True to False, so Django now only accepts cookies signed with the unambiguous new salt derivation by default. medium confirmed CVE-2026-6873 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/238 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/238 Wed, 03 Jun 2026 14:31:00 GMT Django's get_signed_cookie derived its signing salt by concatenating the cookie name (key) and salt arguments using simple string concatenation: `key + salt`. This meant that distinct (name, salt) pairs that produce the same concatenated string (e.g., name='ab', salt='c' and name='a', salt='bc') would use the same signing namespace, allowing a signed cookie created for one context to be accepted in another. The patch fixes this by using an injective encoding that includes the salt length as a prefix, making it impossible for different (name, salt) pairs to collide. Patch landed 3 hours 53 minutes before CVE-2026-6873 was published. low confirmed CVE-2026-6873 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/237 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/237 Wed, 03 Jun 2026 14:30:40 GMT When using EMAIL_USE_TLS with fail_silently=True, a failed STARTTLS handshake would leave self.connection set to a partially-initialized SMTP connection that had not completed TLS negotiation. Subsequent email sends would reuse this unencrypted connection, transmitting emails (including credentials and content) in plaintext. The patch fixes this by only setting self.connection after all configuration steps (STARTTLS and login) succeed, using a temporary self._partial_connection during setup. Patch landed 3 hours 53 minutes before CVE-2026-7666 was published. low confirmed CVE-2026-7666 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/236 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/236 Wed, 03 Jun 2026 14:30:20 GMT Django's UpdateCacheMiddleware performed a case-sensitive check for Cache-Control directives like 'private', 'no-cache', and 'no-store'. If a response manually set 'Cache-Control: Private' (or any mixed/uppercase variant), the middleware would fail to recognize it and cache the response anyway, potentially storing and serving private user data to other users. The patch lowercases the Cache-Control header value before checking for these directives. Patch landed 3 hours 53 minutes before CVE-2026-8404 was published. low confirmed CVE-2026-8404 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/235 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/235 Wed, 03 Jun 2026 14:30:00 GMT Django's UpdateCacheMiddleware and cache_page decorator failed to add 'Authorization' to the Vary header when caching responses to authenticated requests. This meant that a response generated for an authenticated user (with a specific Authorization header) could be served from cache to unauthenticated users or users with different credentials, potentially leaking private/user-specific data. The patch adds 'Authorization' to the Vary header whenever the request contains an Authorization header and the response is not explicitly marked 'Cache-Control: public'. Patch landed 3 hours 53 minutes before CVE-2026-35193 was published. low confirmed CVE-2026-35193 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/234 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/234 Wed, 03 Jun 2026 14:29:44 GMT The `has_vary_header()` function in Django's cache utility failed to strip whitespace from individual Vary header values before comparison. This meant that a `Vary: *` header with surrounding whitespace (e.g., `Vary: * ` or `Vary: * `) would not be recognized as containing the wildcard, causing `UpdateCacheMiddleware` to cache responses that should never be cached (responses with `Vary: *` should not be cached as they vary on all request headers). This could lead to private/personalized data being stored in and served from the cache to unintended users. Patch landed 3 hours 53 minutes before CVE-2026-48587 was published. low confirmed CVE-2026-48587 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/189 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/189 Fri, 22 May 2026 15:17:35 GMT The `reason_phrase` setter in Django's `HttpResponseBase` class did not validate or sanitize control characters, allowing an attacker to inject arbitrary HTTP headers via carriage return (\\r) and newline (\\n) characters in the reason phrase. This is an HTTP Response Splitting vulnerability where a crafted reason phrase could inject additional headers or manipulate the HTTP response structure. The patch adds a regex check that raises `BadHeaderError` when control characters are detected in the reason phrase. medium verified https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/178 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/178 Wed, 20 May 2026 12:19:15 GMT Before the patch, the Django admin change form allowed actions to be executed against arbitrary objects, not just the object being edited. An attacker could craft a POST request to a change form URL (for object A) but include the ACTION_CHECKBOX_NAME value of a different object (object B), causing the action to be executed on object B instead. This allowed privilege escalation or unauthorized modification/deletion of objects the user might not intend to affect. The fix adds a server-side check ensuring the checkbox value matches exactly the object being edited. Patch landed 76 days 6 hours 26 minutes before CVE-2026-15920 was published. high confirmed CVE-2026-15920 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/167 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/167 Tue, 05 May 2026 15:57:18 GMT Django's UpdateCacheMiddleware erroneously cached responses where the Vary header contained an asterisk ('*'). Per RFC 7231, 'Vary: *' means the response is unique per request and must never be served from cache, as it may contain private/user-specific data. An attacker could potentially receive cached private data intended for another user if the server responded with Vary: * but Django still stored and served it from cache. Patch landed 5 hours 59 minutes before CVE-2026-6907 was published. low confirmed CVE-2026-6907 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/168 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/168 Tue, 05 May 2026 15:57:33 GMT When SESSION_SAVE_EVERY_REQUEST=True, Django's session middleware would set a session cookie on responses but failed to include 'Vary: Cookie' in the response headers when the session was not explicitly modified. This meant caching proxies could cache a response containing a Set-Cookie header with a specific session key, and serve that cached response (with that session cookie) to other users, allowing an attacker to steal or fixate another user's session. The patch ensures that whenever a session cookie is set in the response, the Vary: Cookie header is also added. Patch landed 5 hours 59 minutes before CVE-2026-35192 was published. low confirmed CVE-2026-35192 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/169 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/169 Tue, 05 May 2026 15:57:51 GMT In Django's ASGI deployments, the MemoryFileUploadHandler relied solely on the Content-Length header to determine whether a file upload should be stored in memory. Since ASGI doesn't guarantee that Content-Length accurately reflects the actual request body size (e.g., with chunked transfer encoding or a deliberately understated header), an attacker could send a multipart file upload with a small or missing Content-Length value but a very large body, bypassing FILE_UPLOAD_MAX_MEMORY_SIZE and forcing the server to load arbitrarily large files into memory. The patch fixes this by seeking to the end of the stream to measure the actual size when possible, falling back to Content-Length only for non-seekable streams. Patch landed 5 hours 59 minutes before CVE-2026-5766 was published. low confirmed CVE-2026-5766 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/158 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/158 Tue, 28 Apr 2026 17:50:21 GMT Before the patch, when a POST request was submitted to the Django admin changelist view with list_editable fields, the formset used for saving data was constructed directly with `FormSet(request.POST, request.FILES, queryset=modified_objects)` rather than going through `_get_formset_with_permissions()`. This meant the per-object permission check that removes editable fields for unauthorized objects was bypassed during form submission. An authenticated admin user with restricted per-object change permissions could modify objects they were not permitted to edit by crafting a POST request to the changelist view. high verified https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/65 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/65 Tue, 03 Mar 2026 14:31:34 GMT In multi-threaded Django applications, the file-based cache backend and filesystem storage used temporary umask changes (via os.umask()) to control directory permissions when creating directories. Because os.umask() is a process-wide operation, a temporary umask change in one thread could affect directory/file creation in other threads, resulting in file system objects being created with unintended (potentially overly permissive) permissions. The patch replaces the umask manipulation approach with a safe_makedirs() function that uses os.chmod() after os.mkdir() to enforce the exact requested permissions. Patch landed 3 hours 22 minutes before CVE-2026-25674 was published. low confirmed CVE-2026-25674 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/66 https://github.com/spaceraccoon/vulnerability-spoiler-alert/issues/66 Tue, 03 Mar 2026 14:31:49 GMT Django's URLField.to_python() used urlsplit() to detect URL schemes, which on Windows performs NFKC Unicode normalization. This normalization is disproportionately slow for inputs containing certain Unicode characters (e.g., characters like '¾'), allowing an attacker to craft a POST payload that causes excessive CPU consumption. The patch replaces urlsplit() with str.partition(':') for scheme detection, avoiding Unicode normalization entirely. Patch landed 3 hours 22 minutes before CVE-2026-25673 was published. medium confirmed CVE-2026-25673