CVE-2014-0474

Django versions before 1.8.16, 1.9.11, and 1.10.3, when DEBUG is enabled, allow remote attackers to conduct DNS rebinding attacks due to failure to validate the HTTP Host header against ALLOWED_HOSTS.

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.

The utils.http.is_safe_url function in Django before 1.8.10 and 1.9.x before 1.9.3 allows remote attackers to redirect users to arbitrary web sites. This can lead to phishing attacks or potentially cross-site scripting (XSS) attacks via a URL containing basic authentication.

Django versions before 1.4.21, 1.5.x through 1.6.x, 1.7.x before 1.7.9, and 1.8.x before 1.8.3 are vulnerable to denial of service attacks. Attackers can exploit unique session keys to consume session store resources.

An issue was discovered in versions 6.0 before 6.0.5 and 5.2 before 5.2.14 related to ASGI requests that can bypass the `FILE_UPLOAD_MAX_MEMORY_SIZE` limit when the `Content-Length` header is missing or understated. This may lead to large files being loaded into memory, causing service degradation.

An issue was discovered in versions 6.0 before 6.0.5 and 5.2 before 5.2.14 regarding response headers that do not vary on cookies if a session is not modified, while `SESSION_SAVE_EVERY_REQUEST` is set to `True`. A remote attacker can steal a user's session after that user visits a cached public page.

In Django 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28, a vulnerability was found in raster lookups on RasterField (PostGIS only). Remote attackers can inject SQL via the band index parameter.

Django versions 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, making it easier for remote attackers to gain access to the database server.

An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. django.contrib.admin.utils.display_for_field() renders URLField values as clickable links in the admin without validating the URL. A value stored with an unsafe scheme is displayed as a link on changelist and read-only admin pages, which allows cross-site scripting against staff users who click the link. Exploitation requires the unsafe value to already be stored in the database. URLField validation through a ModelForm or the admin rejects unsafe schemes, so this affects applications that persist URLField data without running model validation, for example through direct queryset writes, deserialization, or bulk import of untrusted input.

In Django 5.2 before 5.2.17 and 6.0 before 6.0.8, an issue was discovered in GeoDjango where parsing deeply nested GEOMETRYCOLLECTION objects (as WKT, WKB, or hex-WKB) can lead to unbounded recursion and a segmentation fault in the GEOS library, potentially causing denial of service. Spatial field lookups and the GeometryField form field are also affected.