Python/django/1.8.14
A high-level Python web framework that encourages rapid development and clean, pragmatic design.
https://pypi.org/project/django
BSD
12 Security Vulnerabilities
Django Denial-of-service possibility in truncatechars_html and truncatewords_html template filters
- https://nvd.nist.gov/vuln/detail/CVE-2018-7537
- https://github.com/advisories/GHSA-2f9x-5v75-3qv4
- https://access.redhat.com/errata/RHSA-2018:2927
- https://access.redhat.com/errata/RHSA-2019:0265
- https://lists.debian.org/debian-lts-announce/2018/03/msg00006.html
- https://usn.ubuntu.com/3591-1/
- https://www.debian.org/security/2018/dsa-4161
- https://www.djangoproject.com/weblog/2018/mar/06/security-releases/
- http://www.securityfocus.com/bid/103357
- https://github.com/django/django/commit/94c5da1d17a6b0d378866c66b605102c19f7988c
- https://github.com/django/django/commit/a91436360b79a6ff995c3e5018bcc666dfaf1539
- https://github.com/django/django/commit/d17974a287a6ea2e361daff88fcc004cbd6835fa
- https://usn.ubuntu.com/3591-1
- https://www.djangoproject.com/weblog/2018/mar/06/security-releases
- https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2018-6.yaml
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.
Improper Input Validation in Django
- https://nvd.nist.gov/vuln/detail/CVE-2019-3498
- https://github.com/advisories/GHSA-337x-4q8g-prc5
- https://docs.djangoproject.com/en/dev/releases/security/
- https://groups.google.com/forum/#!topic/django-announce/VYU7xQQTEPQ
- https://lists.debian.org/debian-lts-announce/2019/01/msg00005.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/HVXDOVCXLD74SHR2BENGCE2OOYYYWJHZ/
- https://usn.ubuntu.com/3851-1/
- https://www.debian.org/security/2019/dsa-4363
- https://www.djangoproject.com/weblog/2019/jan/04/security-releases/
- http://www.securityfocus.com/bid/106453
- https://web.archive.org/web/20200227094237/http://www.securityfocus.com/bid/106453
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.page_not_found()
, leading to content spoofing (in a 404 error page) if a user fails to recognize that a crafted URL has malicious content.
Django Open redirect and possible XSS attack via user-supplied numeric redirect URLs
- https://nvd.nist.gov/vuln/detail/CVE-2017-7233
- https://github.com/advisories/GHSA-37hp-765x-j95x
- https://access.redhat.com/errata/RHSA-2017:1445
- https://access.redhat.com/errata/RHSA-2017:1451
- https://access.redhat.com/errata/RHSA-2017:1462
- https://access.redhat.com/errata/RHSA-2017:1470
- https://access.redhat.com/errata/RHSA-2017:1596
- https://access.redhat.com/errata/RHSA-2017:3093
- https://access.redhat.com/errata/RHSA-2018:2927
- https://www.djangoproject.com/weblog/2017/apr/04/security-releases/
- http://www.debian.org/security/2017/dsa-3835
- http://www.securityfocus.com/bid/97406
- http://www.securitytracker.com/id/1038177
- https://github.com/django/django/commit/254326cb3682389f55f886804d2c43f7b9f23e4f
- https://github.com/django/django/commit/8339277518c7d8ec280070a780915304654e3b66
- https://github.com/django/django/commit/f824655bc2c50b19d2f202d7640785caabc82787
- https://www.djangoproject.com/weblog/2017/apr/04/security-releases
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.is_safe_url()
) considered some numeric URLs safe
when they shouldn't be, aka an open redirect vulnerability. Also, if a developer relies on is_safe_url()
to provide safe redirect targets and puts such a URL into a link, they could suffer from an XSS attack.
Django DNS Rebinding Vulnerability
- https://nvd.nist.gov/vuln/detail/CVE-2016-9014
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OG5ROMUPS6C7BXELD3TAUUH7OBYV56WQ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QXDKJYHN74BWY3P7AR2UZDVJREQMRE6S/
- https://www.djangoproject.com/weblog/2016/nov/01/security-releases/
- http://www.debian.org/security/2017/dsa-3835
- http://www.ubuntu.com/usn/USN-3115-1
- https://web.archive.org/web/20210123185619/http://www.securityfocus.com/bid/94068
- https://web.archive.org/web/20211204043252/http://www.securitytracker.com/id/1037159
- https://github.com/advisories/GHSA-3f2c-jm6v-cr35
- https://github.com/django/django/commit/45acd6d836895a4c36575f48b3fb36a3dae98d19
- https://github.com/django/django/commit/884e113838e5a72b4b0ec9e5e87aa480f6aa4472
- https://github.com/django/django/commit/c401ae9a7dfb1a94a8a61927ed541d6f93089587
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OG5ROMUPS6C7BXELD3TAUUH7OBYV56WQ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QXDKJYHN74BWY3P7AR2UZDVJREQMRE6S
- https://www.djangoproject.com/weblog/2016/nov/01/security-releases
Django before 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before 1.10.3, when settings.DEBUG is True, allow remote attackers to conduct DNS rebinding attacks by leveraging failure to validate the HTTP Host header against settings.ALLOWED_HOSTS.
Path Traversal in Django
- https://nvd.nist.gov/vuln/detail/CVE-2021-33203
- https://github.com/advisories/GHSA-68w8-qjq3-2gfm
- https://docs.djangoproject.com/en/3.2/releases/security/
- https://groups.google.com/forum/#!forum/django-announce
- https://www.djangoproject.com/weblog/2021/jun/02/security-releases/
- https://security.netapp.com/advisory/ntap-20210727-0004/
- https://github.com/django/django/commit/053cc9534d174dc89daba36724ed2dcb36755b90
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/B4SQG2EAF4WCI2SLRL6XRDJ3RPK3ZRDV/
- https://github.com/django/django/commit/20c67a0693c4ede2b09af02574823485e82e4c8f
- https://github.com/django/django/commit/dfaba12cda060b8b292ae1d271b44bf810b1c5b9
- https://docs.djangoproject.com/en/3.2/releases/security
- https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2021-98.yaml
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/B4SQG2EAF4WCI2SLRL6XRDJ3RPK3ZRDV
- https://security.netapp.com/advisory/ntap-20210727-0004
- https://www.djangoproject.com/weblog/2021/jun/02/security-releases
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.
Django CSRF Protection Bypass
- https://nvd.nist.gov/vuln/detail/CVE-2016-7401
- https://www.djangoproject.com/weblog/2016/sep/26/security-releases/
- http://rhn.redhat.com/errata/RHSA-2016-2038.html
- http://rhn.redhat.com/errata/RHSA-2016-2039.html
- http://rhn.redhat.com/errata/RHSA-2016-2040.html
- http://rhn.redhat.com/errata/RHSA-2016-2041.html
- http://rhn.redhat.com/errata/RHSA-2016-2042.html
- http://rhn.redhat.com/errata/RHSA-2016-2043.html
- http://www.debian.org/security/2016/dsa-3678
- http://www.ubuntu.com/usn/USN-3089-1
- https://web.archive.org/web/20200227223637/http://www.securityfocus.com/bid/93182
- https://web.archive.org/web/20210927195154/http://www.securitytracker.com/id/1036899
- https://github.com/advisories/GHSA-crhm-qpjc-cm64
- https://github.com/django/django/commit/6fe846a8f08dc959003f298b5407e321c6fe3735
- https://github.com/django/django/commit/6118ab7d0676f0d622278e5be215f14fb5410b6a
- https://github.com/django/django/commit/d1bc980db1c0fffd6d60677e62f70beadb9fe64a
- https://www.djangoproject.com/weblog/2016/sep/26/security-releases
- https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2016-3.yaml
The cookie parsing code in Django before 1.8.15 and 1.9.x before 1.9.10, when used on a site with Google Analytics, allows remote attackers to bypass an intended CSRF protection mechanism by setting arbitrary cookies.
Django open redirect
- https://nvd.nist.gov/vuln/detail/CVE-2017-7234
- https://github.com/advisories/GHSA-h4hv-m4h4-mhwg
- https://www.djangoproject.com/weblog/2017/apr/04/security-releases/
- http://www.debian.org/security/2017/dsa-3835
- http://www.securityfocus.com/bid/97401
- http://www.securitytracker.com/id/1038177
- https://web.archive.org/web/20170429023907/http://www.securitytracker.com/id/1038177
- https://web.archive.org/web/20170526042328/http://www.securityfocus.com/bid/97401
- https://github.com/django/django/commit/2a9f6ef71b8e23fd267ee2be1be26dde8ab67037
- https://github.com/django/django/commit/4a6b945dffe8d10e7cec107d93e6efaebfbded29
- https://github.com/django/django/commit/5f1ffb07afc1e59729ce2b283124116d6c0659e4
- https://www.djangoproject.com/weblog/2017/apr/04/security-releases
- https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2017-10.yaml
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.
SQL injection in Django
- https://nvd.nist.gov/vuln/detail/CVE-2020-7471
- https://github.com/advisories/GHSA-hmr4-m2h5-33qx
- https://github.com/django/django/commit/eb31d845323618d688ad429479c6dda973056136
- https://docs.djangoproject.com/en/3.0/releases/security/
- https://groups.google.com/forum/#!topic/django-announce/X45S86X5bZI
- https://www.djangoproject.com/weblog/2020/feb/03/security-releases/
- https://www.openwall.com/lists/oss-security/2020/02/03/1
- http://www.openwall.com/lists/oss-security/2020/02/03/1
- https://usn.ubuntu.com/4264-1/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4A2AP4T7RKPBCLTI2NNQG3T6MINDUUMZ/
- https://seclists.org/bugtraq/2020/Feb/30
- https://security.gentoo.org/glsa/202004-17
- https://security.netapp.com/advisory/ntap-20200221-0006/
- https://www.debian.org/security/2020/dsa-4629
- https://github.com/django/django/commit/001b0634cd309e372edb6d7d95d083d02b8e37bd
- https://github.com/django/django/commit/505826b469b16ab36693360da9e11fd13213421b
- https://github.com/django/django/commit/c67a368c16e4680b324b4f385398d638db4d8147
- https://www.djangoproject.com/weblog/2020/feb/03/security-releases
- https://usn.ubuntu.com/4264-1
- https://security.netapp.com/advisory/ntap-20200221-0006
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4A2AP4T7RKPBCLTI2NNQG3T6MINDUUMZ
- https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2020-35.yaml
- https://docs.djangoproject.com/en/3.0/releases/security
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.
Django user with hardcoded password created when running tests on Oracle
- https://nvd.nist.gov/vuln/detail/CVE-2016-9013
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OG5ROMUPS6C7BXELD3TAUUH7OBYV56WQ/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QXDKJYHN74BWY3P7AR2UZDVJREQMRE6S/
- https://www.djangoproject.com/weblog/2016/nov/01/security-releases/
- http://www.debian.org/security/2017/dsa-3835
- http://www.securityfocus.com/bid/94069
- http://www.securitytracker.com/id/1037159
- http://www.ubuntu.com/usn/USN-3115-1
- https://github.com/advisories/GHSA-mv8g-fhh6-6267
- https://github.com/django/django/commit/34e10720d81b8d407aa14d763b6a7fe8f13b4f2e
- https://github.com/django/django/commit/4844d86c7728c1a5a3bbce4ad336a8d32304072b
- https://github.com/django/django/commit/70f99952965a430daf69eeb9947079aae535d2d0
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OG5ROMUPS6C7BXELD3TAUUH7OBYV56WQ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QXDKJYHN74BWY3P7AR2UZDVJREQMRE6S
- https://www.djangoproject.com/weblog/2016/nov/01/security-releases
Django 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before 1.10.3 use a hardcoded password for a temporary database user created when running tests with an Oracle database, which makes it easier for remote attackers to obtain access to the database server by leveraging failure to manually specify a password in the database settings TEST dictionary.
Django Denial-of-service possibility in urlize and urlizetrunc template filters
- https://nvd.nist.gov/vuln/detail/CVE-2018-7536
- https://github.com/advisories/GHSA-r28v-mw67-m5p9
- https://access.redhat.com/errata/RHSA-2018:2927
- https://access.redhat.com/errata/RHSA-2019:0051
- https://access.redhat.com/errata/RHSA-2019:0082
- https://access.redhat.com/errata/RHSA-2019:0265
- https://lists.debian.org/debian-lts-announce/2018/03/msg00006.html
- https://usn.ubuntu.com/3591-1/
- https://www.debian.org/security/2018/dsa-4161
- https://www.djangoproject.com/weblog/2018/mar/06/security-releases/
- http://www.securityfocus.com/bid/103361
- https://github.com/django/django/commit/1ca63a66ef3163149ad822701273e8a1844192c2
- https://github.com/django/django/commit/abf89d729f210c692a50e0ad3f75fb6bec6fae16
- https://github.com/django/django/commit/e157315da3ae7005fa0683ffc9751dbeca7306c8
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.
Django Potential account hijack via password reset form
- https://nvd.nist.gov/vuln/detail/CVE-2019-19844
- https://github.com/advisories/GHSA-vfq6-hq5r-27r6
- https://github.com/django/django/commit/5b1fbcef7a8bec991ebe7b2a18b5d5a95d72cb70
- https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2
- https://docs.djangoproject.com/en/dev/releases/security/
- https://groups.google.com/forum/#!topic/django-announce/3oaB2rVH3a0
- https://seclists.org/bugtraq/2020/Jan/9
- https://security.netapp.com/advisory/ntap-20200110-0003/
- https://usn.ubuntu.com/4224-1/
- https://www.debian.org/security/2020/dsa-4598
- https://www.djangoproject.com/weblog/2019/dec/18/security-releases/
- http://packetstormsecurity.com/files/155872/Django-Account-Hijack.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/HCM2DPUI7TOZWN4A6JFQFUVQ2XGE7GUD/
- https://security.gentoo.org/glsa/202004-17
- https://github.com/django/django/commit/302a4ff1e8b1c798aab97673909c7a3dfda42c26
- https://github.com/django/django/commit/4d334bea06cac63dc1272abcec545b85136cca0e
- https://docs.djangoproject.com/en/dev/releases/security
- https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2019-16.yaml
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/HCM2DPUI7TOZWN4A6JFQFUVQ2XGE7GUD
- https://security.netapp.com/advisory/ntap-20200110-0003
- https://usn.ubuntu.com/4224-1
- https://www.djangoproject.com/weblog/2019/dec/18/security-releases
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.)
Uncontrolled Memory Consumption in Django
- https://nvd.nist.gov/vuln/detail/CVE-2019-6975
- https://github.com/advisories/GHSA-wh4h-v3f2-r2pp
- https://docs.djangoproject.com/en/dev/releases/security/
- https://groups.google.com/forum/#!topic/django-announce/WTwEAprR0IQ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/66WMXHGBXD7GSM3PEXVCMCAGLMQYHZCU/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/HVXDOVCXLD74SHR2BENGCE2OOYYYWJHZ/
- https://seclists.org/bugtraq/2019/Jul/10
- https://usn.ubuntu.com/3890-1/
- https://www.debian.org/security/2019/dsa-4476
- https://www.djangoproject.com/weblog/2019/feb/11/security-releases/
- https://www.openwall.com/lists/oss-security/2019/02/11/1
- http://www.securityfocus.com/bid/106964
- https://github.com/django/django/commit/0bbb560183fabf0533289700845dafa94951f227
- https://github.com/django/django/commit/1f42f82566c9d2d73aff1c42790d6b1b243f7676
- https://github.com/django/django/commit/40cd19055773705301c3428ed5e08a036d2091f3
- https://web.archive.org/web/20200227084713/http://www.securityfocus.com/bid/106964
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.