The verify_exists functionality in the URLField implementation in Django before 1.2.7 and 1.3.x before 1.3.1 originally tests a URL's validity through a HEAD request, but then uses a GET request for the new target URL in the case of a redirect, which might allow remote attackers to trigger arbitrary GET requests with an unintended source IP address via a crafted Location header.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - The verify_exists functionality in the URLField implementation in Django before 1.2.7 and 1.3.x before
    1.3.1 originally tests a URL's validity through a HEAD request, but then uses a GET request for the new
    target URL in the case of a redirect, which might allow remote attackers to trigger arbitrary GET requests
    with an unintended source IP address via a crafted Location header. (CVE-2011-4138)

python-django update version to 1.2.7 fixes several security issues including denial of service, CSRF and information leaks:
https://www.djangoproject.com/weblog/2011/sep/10/127/

Pall McMillan discovered that Django used the root namespace when storing cached session data. A remote attacker could exploit this to modify sessions. (CVE-2011-4136)

Paul McMillan discovered that Django would not timeout on arbitrary URLs when the application used URLFields. This could be exploited by a remote attacker to cause a denial of service via resource exhaustion.
(CVE-2011-4137)

Paul McMillan discovered that while Django would check the validity of a URL via a HEAD request, it would instead use a GET request for the target of a redirect. This could potentially be used to trigger arbitrary GET requests via a crafted Location header. (CVE-2011-4138)

It was discovered that Django would sometimes use a request's HTTP Host header to construct a full URL. A remote attacker could exploit this to conduct host header cache poisoning attacks via a crafted request. (CVE-2011-4139).

Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

Paul McMillan, Mozilla and the Django core team discovered several vulnerabilities in Django, a Python web framework :

  - CVE-2011-4136     When using memory-based sessions and caching, Django     sessions are stored directly in the root namespace of     the cache. When user data is stored in the same cache, a     remote user may take over a session.

  - CVE-2011-4137, CVE-2011-4138     Django's field type URLfield by default checks supplied     URL's by issuing a request to it, which doesn't time     out. A Denial of Service is possible by supplying     specially prepared URL's that keep the connection open     indefinately or fill the Django's server memory.

  - CVE-2011-4139     Django used X-Forwarded-Host headers to construct full     URL's. This header may not contain trusted input and     could be used to poison the cache.

  - CVE-2011-4140     The CSRF protection mechanism in Django does not     properly handle web-server configurations supporting     arbitrary HTTP Host headers, which allows remote     attackers to trigger unauthenticated forged requests.

ID	Name	Product	Family	Type	Severity
433521	SCA: security update for Django (GHSA-wxg3-mfph-qg9w)	Tenable Cloud Security	SCA Checks	Local	high
433521	SCA: security update for Django (GHSA-wxg3-mfph-qg9w)	Tenable Self-Hosted Container Security	SCA Checks	Local	high
74633	openSUSE Security Update : python-django (openSUSE-SU-2012:0653-1)	Nessus	SuSE Local Security Checks	Local	medium
57061	Ubuntu 10.04 LTS / 10.10 / 11.04 / 11.10 : python-django vulnerabilities (USN-1297-1)	Nessus	Ubuntu Local Security Checks	Local	medium
56671	Debian DSA-2332-1 : python-django - several issues	Nessus	Debian Local Security Checks	Local	medium

Detections

Analytics

CVE-2011-4138

high

Tenable Plugins

high

high

medium

medium

medium