Django

Latest version: v5.1.3

Safety actively analyzes 681757 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 34 of 54

1.10.8

Not secure
===========================

*September 5, 2017*

Django 1.10.8 fixes a security issue in 1.10.7.

CVE-2017-12794: Possible XSS in traceback section of technical 500 debug page
=============================================================================

In older versions, 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.


===========================

1.10.7

Not secure
===========================

*April 4, 2017*

Django 1.10.7 fixes two security issues and a bug in 1.10.6.

CVE-2017-7233: Open redirect and possible XSS attack via user-supplied numeric redirect URLs
============================================================================================

Django relies on user input in some cases (e.g.
``django.contrib.auth.views.login()`` and :doc:`i18n </topics/i18n/index>`)
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 (e.g. ``http:999999999``) "safe" when they shouldn't be.

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.

CVE-2017-7234: Open redirect vulnerability in ``django.views.static.serve()``
=============================================================================

A maliciously crafted URL to a Django site using the
:func:`~django.views.static.serve` view could redirect to any other domain. The
view no longer does any redirects as they don't provide any known, useful
functionality.

Note, however, that this view has always carried a warning that it is not
hardened for production use and should be used only as a development aid.

Bugfixes
========

* Made admin's ``RelatedFieldWidgetWrapper`` use the wrapped widget's
``value_omitted_from_data()`` method (:ticket:`27905`).

* Fixed model form ``default`` fallback for ``SelectMultiple``
(:ticket:`27993`).


===========================

1.10.6

Not secure
===========================

*March 1, 2017*

Django 1.10.6 fixes several bugs in 1.10.5.

Bugfixes
========

* Fixed ``ClearableFileInput``’s "Clear" checkbox on model form fields where
the model field has a ``default`` (:ticket:`27805`).

* Fixed ``RequestDataTooBig`` and ``TooManyFieldsSent`` exceptions crashing
rather than generating a bad request response (:ticket:`27820`).

* Fixed a crash on Oracle and PostgreSQL when subtracting ``DurationField``
or ``IntegerField`` from ``DateField`` (:ticket:`27828`).

* Fixed query expression date subtraction accuracy on PostgreSQL for
differences larger than a month (:ticket:`27856`).

* Fixed a ``GDALException`` raised by ``GDALClose`` on GDAL ≥ 2.0
(:ticket:`27479`).


===========================

1.10.5

Not secure
===========================

*January 4, 2017*

Django 1.10.5 fixes several bugs in 1.10.4.

Bugfixes
========

* Fixed a crash in the debug view if ``request.user`` can't be retrieved, such
as if the database is unavailable (:ticket:`27567`).

* Fixed occasional missing plural forms in ``JavaScriptCatalog``
(:ticket:`27418`).

* Fixed a regression in the ``timesince`` and ``timeuntil`` filters that caused
incorrect results for dates in a leap year (:ticket:`27637`).

* Fixed a regression where ``collectstatic`` overwrote newer files in remote
storages (:ticket:`27658`).


===========================

1.10.4

Not secure
===========================

*December 1, 2016*

Django 1.10.4 fixes several bugs in 1.10.3.

Bugfixes
========

* Quoted the Oracle test user's password in queries to fix the "ORA-00922:
missing or invalid option" error when the password starts with a number or
special character (:ticket:`27420`).

* Fixed incorrect ``app_label`` / ``model_name`` arguments for
``allow_migrate()`` in ``makemigrations`` migration consistency checks
(:ticket:`27461`).

* Made ``Model.delete(keep_parents=True)`` preserve parent reverse
relationships in multi-table inheritance (:ticket:`27407`).

* Fixed a ``QuerySet.update()`` crash on SQLite when updating a
``DateTimeField`` with an ``F()`` expression and a ``timedelta``
(:ticket:`27544`).

* Prevented ``LocaleMiddleware`` from redirecting on URLs that should return
404 when using ``prefix_default_language=False`` (:ticket:`27402`).

* Prevented an unnecessary index from being created on an InnoDB ``ForeignKey``
when the field was added after the model was created (:ticket:`27558`).


===========================

1.10.3

Not secure
===========================

*November 1, 2016*

Django 1.10.3 fixes two security issues and several bugs in 1.10.2.

User with hardcoded password created when running tests on Oracle
=================================================================

When running tests with an Oracle database, Django creates a temporary database
user. In older versions, if a password isn't manually specified in the database
settings ``TEST`` dictionary, a hardcoded password is used. This could allow
an attacker with network access to the database server to connect.

This user is usually dropped after the test suite completes, but not when using
the ``manage.py test --keepdb`` option or if the user has an active session
(such as an attacker's connection).

A randomly generated password is now used for each test run.

DNS rebinding vulnerability when ``DEBUG=True``
===============================================

Older versions of Django don't validate the ``Host`` header against
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
vulnerable to a `DNS rebinding attack
<https://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.

While Django doesn't ship a module that allows remote code execution, this is
at least a cross-site scripting vector, which could be quite serious if
developers load a copy of the production database in development or connect to
some production services for which there's no development instance, for
example. If a project uses a package like the ``django-debug-toolbar``, then
the attacker could execute arbitrary SQL, which could be especially bad if the
developers connect to the database with a superuser account.

``settings.ALLOWED_HOSTS`` is now validated regardless of ``DEBUG``. For
convenience, if ``ALLOWED_HOSTS`` is empty and ``DEBUG=True``, the following
variations of localhost are allowed ``['localhost', '127.0.0.1', '::1']``. If
your local settings file has your production ``ALLOWED_HOSTS`` value, you must
now omit it to get those fallback values.

Bugfixes
========

* Allowed ``User.is_authenticated`` and ``User.is_anonymous`` properties to be
tested for ``set`` membership (:ticket:`27309`).

* Fixed a performance regression when running ``migrate`` in projects
with ``RenameModel`` operations (:ticket:`27279`).

* Added ``model_name`` to the ``allow_migrate()`` calls in ``makemigrations``
(:ticket:`27200`).

* Made the ``JavaScriptCatalog`` view respect the ``packages`` argument;
previously it was ignored (:ticket:`27374`).

* Fixed ``QuerySet.bulk_create()`` on PostgreSQL when the number of objects is
a multiple plus one of ``batch_size`` (:ticket:`27385`).

* Prevented ``i18n_patterns()`` from using too much of the URL as the language
to fix a use case for ``prefix_default_language=False`` (:ticket:`27063`).

* Replaced a possibly incorrect redirect from ``SessionMiddleware`` when a
session is destroyed in a concurrent request with a ``SuspiciousOperation``
to indicate that the request can't be completed (:ticket:`27363`).


===========================

Page 34 of 54

Links

Releases

Has known vulnerabilities

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.