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.
In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewordshtml template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.
Recommended action: Upgrade to 5.0.3, 4.2.11 or 3.2.25 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 3.2 before 3.2.24, 4.2 before 4.2.10, and Django 5.0 before 5.0.2. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings.
Recommended action: Upgrade to 5.0.2, 4.2.10 or 3.2.24 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 3.2 before 3.2.22, 4.1 before 4.1.12, and 4.2 before 4.2.6, the django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatecharshtml and truncatewordshtml template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
Recommended action: Upgrade to 4.2.6, 4.1.12 or 3.2.22 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 3.2 before 3.2.21, 4.1 before 4.1.11, and 4.2 before 4.2.5, django.utils.encoding.uritoiri() is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.
Recommended action: Upgrade to 4.2.5, 4.1.11 or 3.2.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 3.2 before 3.2.23, 4.1 before 4.1.13, and 4.2 before 4.2.7. The NFKC normalization is slow on Windows. As a consequence, django.contrib.auth.forms.UsernameField is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.
Recommended action: Upgrade to 4.2.7, 4.1.13 or 3.2.23 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 3.2 before 3.2.20, 4 before 4.1.10, and 4.2 before 4.2.3, EmailValidator and URLValidator are subject to a potential ReDoS (regular expression denial of service) attack via a very large number of domain name labels of emails and URLs.
Recommended action: Upgrade to 4.2.3, 4.1.10 or 3.2.20 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 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
Recommended action: Upgrade to 4.2.1, 4.1.9 or 3.2.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 the Multipart Request Parser in Django 3.2 before 3.2.18, 4.0 before 4.0.10, and 4.1 before 4.1.7. Passing certain inputs (e.g., an excessive number of parts) to multipart forms could result in too many open files or memory exhaustion, and provided a potential vector for a denial-of-service attack.
Recommended action: Upgrade to 4.1.7, 4.0.10 or 3.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.
In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
Recommended action: Upgrade to 4.1.6, 4.0.9 or 3.2.17 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 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
Recommended action: Upgrade to 4.1.2, 4.0.8 or 3.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.
An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
Recommended action: Upgrade to 4.0.7 or 3.2.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 3.2 before 3.2.14 and 4.0 before 4.0.6. The Trunc() and Extract() database functions are subject to SQL injection if untrusted data is used as a kind/lookupname value. Applications that constrain the lookup name and kind choice to a known safe list are unaffected.
Recommended action: Upgrade to 4.0.6 or 3.2.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The getimagedimensions function in the image-handling functionality in Django before 1.3.2 and 1.4.x before 1.4.1 uses a constant chunk size in all attempts to determine dimensions, which allows remote attackers to cause a denial of service (process or thread consumption) via a large TIFF image.
Recommended action: Upgrade to 1.4.1 or 1.3.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The django.forms.ImageField class in the form system in Django before 1.3.2 and 1.4.x before 1.4.1 completely decompresses image data during image validation, which allows remote attackers to cause a denial of service (memory consumption) by uploading an image file.
Recommended action: Upgrade to 1.4.1 or 1.3.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The (1) django.http.HttpResponseRedirect and (2) django.http.HttpResponsePermanentRedirect classes in Django before 1.3.2 and 1.4.x before 1.4.1 do not validate the scheme of a redirect target, which might allow remote attackers to conduct cross-site scripting (XSS) attacks via a data: URL.
Recommended action: Upgrade to 1.4.1 or 1.3.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The django.http.HttpRequest.gethost function in Django 1.3.x before 1.3.4 and 1.4.x before 1.4.2 allows remote attackers to generate and display arbitrary URLs via crafted username and password Host header values.
Recommended action: Upgrade to 1.4.2 or 1.3.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The XML libraries for Python, as used in OpenStack Keystone Essex, Folsom, and Grizzly; Compute (Nova) Essex and Folsom; Cinder Folsom; Django; and possibly other products allow remote attackers to cause a denial of service (resource consumption and crash) via an XML Entity Expansion (XEE) attack.
Recommended action: Upgrade to 1.4.4 or 1.3.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The XML libraries for Python as used in OpenStack Keystone Essex and Folsom, Django, and possibly other products allow remote attackers to read arbitrary files via an XML external entity declaration in conjunction with an entity reference, aka an XML External Entity (XXE) attack.
Recommended action: Upgrade to 1.4.4 or 1.3.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Directory traversal vulnerability in Django 1.4.x before 1.4.7, 1.5.x before 1.5.3, and 1.6.x before 1.6 beta 3 allows remote attackers to read arbitrary files via a file path in the ALLOWEDINCLUDEROOTS setting followed by a .. (dot dot) in a ssi template tag.
Recommended action: Upgrade to 1.5.3 or 1.4.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The authentication framework (django.contrib.auth) in Django 1.4.x before 1.4.8, 1.5.x before 1.5.4, and 1.6.x before 1.6 beta 4 allows remote attackers to cause a denial of service (CPU consumption) via a long password which is then hashed.
Recommended action: Upgrade to 1.5.4 or 1.4.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.9.x before 1.9.2, when ModelAdmin.saveas is set to True, allows remote authenticated users to bypass intended access restrictions and create ModelAdmin objects via the "Save as New" option when editing objects and leveraging the "change" permission.
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site scripting (XSS) vulnerability in the contents function in admin/helpers.py in Django before 1.7.6 and 1.8 before 1.8b2 allows remote attackers to inject arbitrary web script or HTML via a model attribute in ModelAdmin.readonlyfields, as demonstrated by an @property.
Recommended action: Upgrade to 1.7.6 or 1.8b2 (pre-release) 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.flush function in the cacheddb backend in Django 1.8.x before 1.8.2 does not properly flush the session, which allows remote attackers to hijack user sessions via an empty string in the session key.
Recommended action: Upgrade to 1.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The getformat function in utils/formats.py in Django before 1.7.x before 1.7.11, 1.8.x before 1.8.7, and 1.9.x before 1.9rc2 might allow remote attackers to obtain sensitive application secrets via a settings key in place of a date/time format setting, as demonstrated by SECRETKEY.
Recommended action: Upgrade to 1.8.7, 1.7.11 or 1.9rc2 (pre-release) 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.4.18, 1.6.x before 1.6.10, and 1.7.x before 1.7.3 allows remote attackers to spoof WSGI headers by using an (underscore) character instead of a - (dash) character in an HTTP header, as demonstrated by an X-AuthUser header.
Recommended action: Upgrade to 1.7.3, 1.6.10 or 1.4.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.