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.
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a denial of service (CPU consumption) by unloading a multiple files with the same name.
Recommended action: Upgrade to 1.6.6, 1.5.9 or 1.4.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 administrative interface for Django 1.3.x before 1.3.6, 1.4.x before 1.4.4, and 1.5 before release candidate 2 does not check permissions for the history view, which allows remote authenticated administrators to obtain sensitive object history information.
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 form library in Django 1.3.x before 1.3.6, 1.4.x before 1.4.4, and 1.5 before release candidate 2 allows remote attackers to bypass intended resource limits for formsets and cause a denial of service (memory consumption) or trigger server errors via a modified maxnum parameter.
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.
Algorithmic complexity vulnerability in the forms library in Django 1.0 before 1.0.4 and 1.1 before 1.1.1 allows remote attackers to cause a denial of service (CPU consumption) via a crafted (1) EmailField (email address) or (2) URLField (URL) that triggers a large amount of backtracking in a regular expression.
Recommended action: Upgrade to 1.1.1 or 1.0.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 Admin media handler in core/servers/basehttp.py in Django 1.0 and 0.96 does not properly map URL requests to expected "static media files," which allows remote attackers to conduct directory traversal attacks and read arbitrary files via a crafted URL.
Recommended action: Upgrade to 1.0.3 or 0.96.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 administration application in Django 0.91.x, 0.95.x, and 0.96.x stores unauthenticated HTTP POST requests and processes them after successful authentication occurs, which allows remote attackers to conduct cross-site request forgery (CSRF) attacks and delete or modify data via unspecified requests.
Recommended action: Upgrade to 0.96.3, 0.95.4 or 0.91.3 by release line, 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 login form in the administration application in Django 0.91 before 0.91.2, 0.95 before 0.95.3, and 0.96 before 0.96.2 allows remote attackers to inject arbitrary web script or HTML via the URI of a certain previous request.
Recommended action: Upgrade to 0.96.2, 0.95.3 or 0.91.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 internationalization (i18n) framework in Django 0.91, 0.95, 0.95.1, and 0.96, and as used in other products such as PyLucid, when the USEI18N option and the i18n component are enabled, allows remote attackers to cause a denial of service (memory consumption) via many HTTP requests with large Accept-Language headers.
Recommended action: Upgrade to 0.96.1, 0.95.2 or 0.91.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The LazyUser class in the AuthenticationMiddleware for Django 0.95 does not properly cache the user name across requests, which allows remote authenticated users to gain the privileges of a different user.
Recommended action: Upgrade to 1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
bin/compile-messages.py in Django 0.95 does not quote argument strings before invoking the msgfmt program through the os.system function, which allows attackers to execute arbitrary commands via shell metacharacters in a (1) .po or (2) .mo file.
Recommended action: Upgrade to 1.0 or later, 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.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed kwargs.
Recommended action: Upgrade to 4.0.4, 3.2.13 or 2.2.28 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the options argument, and placing the injection payload in an option name.
Recommended action: Upgrade to 4.0.4, 3.2.13 or 2.2.28 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
Recommended action: Upgrade to 4.0.2, 3.2.12 or 2.2.27 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 MultiPartParser in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2. Passing certain inputs to multipart forms could result in an infinite loop when parsing files.
Recommended action: Upgrade to 4.0.2, 3.2.12 or 2.2.27 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.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
Recommended action: Upgrade to 4.0.1, 3.2.11 or 2.2.26 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
Recommended action: Upgrade to 4.0.1, 3.2.11 or 2.2.26 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.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
Recommended action: Upgrade to 4.0.1, 3.2.11 or 2.2.26 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.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. This issue has low severity, according to the Django security policy.
Recommended action: Upgrade to 3.2.10, 3.1.14 or 2.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.
Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.orderby SQL injection if orderby is untrusted input from a client of a web application.
Recommended action: Upgrade to 3.2.5 or 3.1.13 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.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validateipv4address, and validateipv46address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validateipv4address and validateipv46address are unaffected with Python 3.9.5+..) .
Recommended action: Upgrade to 3.2.4, 3.1.12 or 2.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.
Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories.
Recommended action: Upgrade to 3.2.4, 3.1.12 or 2.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 2.2 before 2.2.22, 3.1 before 3.1.10, and 3.2 before 3.2.2 (with Python 3.9.5+), URLValidator does not prohibit newlines and tabs (unless the URLField form field is used). If an application uses values with newlines in an HTTP response, header injection can occur. Django itself is unaffected because HttpResponse prohibits newlines in HTTP headers.
Recommended action: Upgrade to 3.2.2, 3.1.10 or 2.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 2.2 before 2.2.21, 3.1 before 3.1.9, and 3.2 before 3.2.1, MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names.
Recommended action: Upgrade to 3.2.1, 3.1.9 or 2.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.
In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
Recommended action: Upgrade to 3.1.8, 3.0.14 or 2.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.
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). FILEUPLOADDIRECTORYPERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command.
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.