The following flaw was reported in Django:

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:

http://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.