Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
161 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Recommended action: Upgrade to 3.1.1, 3.0.10 or 2.2.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Django 2.2 before 2.2.18, 3.0 before 3.0.12, and 3.1 before 3.1.6, the django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
Recommended action: Upgrade to 3.1.6, 3.0.12 or 2.2.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django version 2.2 before 2.2.13 and 3.0 before 3.0.7. Query parameters generated by the Django admin ForeignKeyRawIdWidget were not properly URL encoded, leading to a possibility of an XSS attack.
Recommended action: Upgrade to 3.0.7 or 2.2.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django version 2.2 before 2.2.13 and 3.0 before 3.0.7. In cases where a memcached backend does not perform key validation, passing malformed cache keys could result in a key collision, and potential data leakage.
Recommended action: Upgrade to 3.0.7 or 2.2.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL.
Recommended action: Upgrade to 3.0.4, 2.2.11 or 1.11.29 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Django 1.11 before 1.11.28, 2.2 before 2.2.10, and 3.0 before 3.0.3 allows SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Recommended action: Upgrade to 3.0.3, 2.2.10 or 1.11.28 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. (One mitigation in the new releases is to send password reset tokens only to the registered user email address.)
Recommended action: Upgrade to 3.0.1, 2.2.9 or 1.11.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Django 2.1 before 2.1.15 and 2.2 before 2.2.8 allows unintended model editing. A Django model admin displaying inline related models, where the user has view-only permissions to a parent model but edit permissions to the inline model, would be presented with an editing UI, allowing POST requests, for updating the inline model. Directly editing the view-only parent model was not possible, but the parent model's save() method was called, triggering potential side effects, and causing pre and post-save signal handlers to be invoked. (To resolve this, the Django admin is adjusted to require edit permissions on the parent model in order for inline models to be editable.)
Recommended action: Upgrade to 2.2.8 or 2.1.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django 1.11.x before 1.11.23, 2.1.x before 2.1.11, and 2.2.x before 2.2.4. Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed to the QuerySet.filter() function.
Recommended action: Upgrade to 2.2.4, 2.1.11 or 1.11.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django 1.11.x before 1.11.23, 2.1.x before 2.1.11, and 2.2.x before 2.2.4. Due to the behaviour of the underlying HTMLParser, django.utils.html.striptags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Recommended action: Upgrade to 2.2.4, 2.1.11 or 1.11.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django 1.11.x before 1.11.23, 2.1.x before 2.1.11, and 2.2.x before 2.2.4. If passed certain inputs, django.utils.encoding.uritoiri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Recommended action: Upgrade to 2.2.4, 2.1.11 or 1.11.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django 1.11.x before 1.11.23, 2.1.x before 2.1.11, and 2.2.x before 2.2.4. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatecharshtml and truncatewordshtml template filters, which were thus vulnerable.
Recommended action: Upgrade to 2.2.4, 2.1.11 or 1.11.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The session backends in Django before 1.4.21, 1.5.x through 1.6.x, 1.7.x before 1.7.9, and 1.8.x before 1.8.3 allows remote attackers to cause a denial of service (session store consumption) via multiple requests with unique session keys.
Recommended action: Upgrade to 1.8.3, 1.7.9 or 1.4.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECUREPROXYSSLHEADER and SECURESSLREDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Recommended action: Upgrade to 2.2.3, 2.1.10 or 1.11.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django 1.11 before 1.11.21, 2.1 before 2.1.9, and 2.2 before 2.2.2. The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, an unvalidated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Recommended action: Upgrade to 2.2.2, 2.1.9 or 1.11.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
jQuery from 1.1.4 until 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable proto property, it could extend the native Object.prototype.
Recommended action: Upgrade to 2.2.2 or 2.1.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Django 1.11.x before 1.11.19, 2.0.x before 2.0.11, and 2.1.x before 2.1.6 allows Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Recommended action: Upgrade to 2.1.6, 2.0.11 or 1.11.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Django 1.11.x before 1.11.18, 2.0.x before 2.0.10, and 2.1.x before 2.1.5, an Improper Neutralization of Special Elements in Output Used by a Downstream Component issue exists in django.views.defaults.pagenotfound(), leading to content spoofing (in a 404 error page) if a user fails to recognize that a crafted URL has malicious content.
Recommended action: Upgrade to 2.1.5, 2.0.10 or 1.11.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with DEBUG = True (which makes this page accessible) in your production settings.
Recommended action: Upgrade to 1.11.5 or 1.10.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Django 1.10 before 1.10.7, 1.9 before 1.9.13, and 1.8 before 1.8.18 relies on user input in some cases to redirect the user to an "on success" URL. The security check for these redirects (namely django.utils.http.issafeurl()) considered some numeric URLs "safe" when they shouldn't be, aka an open redirect vulnerability. Also, if a developer relies on issafeurl() to provide safe redirect targets and puts such a URL into a link, they could suffer from an XSS attack.
Recommended action: Upgrade to 1.10.7, 1.9.13 or 1.8.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A maliciously crafted URL to a Django (1.10 before 1.10.7, 1.9 before 1.9.13, and 1.8 before 1.8.18) site using the django.views.static.serve() view could redirect to any other domain, aka an open redirect vulnerability.
Recommended action: Upgrade to 1.10.7, 1.9.13 or 1.8.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable.
Recommended action: Upgrade to 2.0.3, 1.11.11 or 1.8.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatecharshtml and truncatewordshtml template filters, which were thus vulnerable.
Recommended action: Upgrade to 2.0.3, 1.11.11 or 1.8.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect.
Recommended action: Upgrade to 2.0.8 or 1.11.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
django.contrib.auth.forms.AuthenticationForm in Django 2.0 before 2.0.2, and 1.11.8 and 1.11.9, allows remote attackers to obtain potentially sensitive information by leveraging data exposure from the confirmloginallowed() method, as demonstrated by discovering whether a user account is inactive.
Recommended action: Upgrade to 2.0.2 or 1.11.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.