django.contrib.sessions in Django before 1.2.7 and 1.3.x before 1.3.1, when session data is stored in the cache, uses the root namespace for both session identifiers and application-data keys, which allows remote attackers to modify a session by triggering use of a key that is equal to that session's identifier.

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

  - django.contrib.sessions in Django before 1.2.7 and 1.3.x before 1.3.1, when session data is stored in the
    cache, uses the root namespace for both session identifiers and application-data keys, which allows remote
    attackers to modify a session by triggering use of a key that is equal to that session's identifier.
    (CVE-2011-4136)

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
422293	SCA: security update for Django (GHSA-x88j-93vc-wpmp)	Tenable Cloud Security	SCA Checks	Local	medium
422293	SCA: security update for Django (GHSA-x88j-93vc-wpmp)	Tenable Self-Hosted Container Security	SCA Checks	Local	medium
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-4136

medium

Tenable Plugins

medium

medium

medium

medium

medium