CVE-2011-4136: django.contrib.sessions - Session Modification Vulnerability

django Updated 02 Oct 2025

Summary

23/07/2018

Disclosed on

CVE-2011-4136

CVE

Yes i

Fix available

Moderate

Severity

4.0

CVSS Score

CVE-2011-4136: Session manipulation in Django. Affects django across 2 version ranges.

< 1.2.7 >= 1.3, < 1.3.1

Fixed in 1.2.7 or 1.3.1, depending on the release line you run. How to fix ↓

Also tracked for

python-django · Debian:11

The same CVE-2011-4136 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.

Free scan

Check if this vulnerability affects your application

Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.

Check my app free

No signup required · Results in about 60 seconds

Upload your dependency manifest or SBOM

Drag & drop your file here or Browse

Java Javascript PHP Python Go Rust Ruby Dart C/C++ Elixir CycloneDX SPDX

Upload a supported dependency manifest or SBOM. No installation or source-code access required.

See supported files and SBOM formats

SBOM sbom.json · bom.json · bom.xml · *.spdx.json · *.cdx.json · *.cdx.xml

Java pom.xml · gradle.lockfile · buildscript-gradle.lockfile

Javascript package-lock.json · yarn.lock · pnpm-lock.yaml

PHP composer.lock

Python poetry.lock · requirements.txt · Pipfile.lock

Go go.mod

Rust Cargo.lock

Ruby Gemfile.lock

Dart pubspec.lock

C/C++ conan.lock

Elixir mix.lock

Enter your work email to receive your report link.

Verify your email to view the full report and start 30 days of continuous monitoring. No credit card required.

Background

Django is a popular Python web framework that simplifies the development of web applications. It includes various modules, including django.contrib.sessions, which handles session management. Sessions allow web applications to store user-specific data between requests. However, in Django versions before 1.2.7 and 1.3.x before 1.3.1, there is a vulnerability in django.contrib.sessions when session data is stored in the cache. This vulnerability arises from the use of the root namespace for both session identifiers and application-data keys. As a result, remote attackers can modify a session by triggering the use of a key that is equal to that session's identifier.

Vulnerability Detail

The vulnerability in django.contrib.sessions allows remote attackers to modify sessions by exploiting the use of a shared namespace for session identifiers and application-data keys. By triggering the use of a key that matches a session's identifier, an attacker can modify the session data. This can lead to various security issues, such as unauthorized access, privilege escalation, or data manipulation. The vulnerability has a moderate severity rating and is classified under CWE-20.

How To Fix

Latest published version: 6.1.2 as of 22 Oct 2026

pip install --upgrade "django==6.1.2"

Upgrading to it may include breaking changes; the versions below are the minimum fixed release for this vulnerability.

If you can't move to the latest

The minimum fixed version depends on the release line you run.

< 1.2.7 1.2.7
```
pip install --upgrade "django==1.2.7"
```
>= 1.3, < 1.3.1 1.3.1
```
pip install --upgrade "django==1.3.1"
```

Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →

Workaround

If upgrading Django is not immediately feasible, a possible workaround is to avoid storing session data in the cache. Instead, consider using other session storage options provided by Django, such as database-backed sessions or file-based sessions. By using these alternative storage methods, the vulnerability can be mitigated.

Conclusion

The vulnerability in django.contrib.sessions allows remote attackers to modify sessions by exploiting the shared namespace for session identifiers and application-data keys. Upgrading Django to the fixed versions or using alternative session storage methods can mitigate this vulnerability. It is important to promptly address this issue to prevent unauthorized access or data manipulation. For further assistance, contact DevNack.com.

See every vulnerability recorded for django →

FAQ

What is the impact of this vulnerability?

The vulnerability allows remote attackers to modify sessions, potentially leading to unauthorized access, privilege escalation, or data manipulation.

Which versions of Django are affected?

The vulnerability affects Django versions before 1.2.7 and 1.3.x before 1.3.1.

How can I check if my Django application is affected?

You can use the Vulert Playground at Vulert Scanner to check if your application is affected by this vulnerability. Simply provide your Pipfile.lock to the playground, and it will alert you in real-time if your application is vulnerable.

Are there any known exploits for this vulnerability?

While specific exploits may not be publicly available, the vulnerability has the potential to be exploited by remote attackers.

Is there any additional support available for vulnerability remediation?

For further support on vulnerability remediation, you can contact info@devnack.com.

References

Related vulnerabilities

Recent vulnerabilities recorded for django.

View all django vulnerabilities →

How To Fix

Latest published version: 6.1.2 as of 22 Oct 2026

pip install --upgrade "django==6.1.2"

Upgrading to it may include breaking changes; the versions below are the minimum fixed release for this vulnerability.

If you can't move to the latest

The minimum fixed version depends on the release line you run.

< 1.2.7 1.2.7
```
pip install --upgrade "django==1.2.7"
```
>= 1.3, < 1.3.1 1.3.1
```
pip install --upgrade "django==1.3.1"
```

Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →

Subscribe to Vulert on Telegram

Daily digest of new CVEs, critical and high severity, affected packages and fixes — plus a weekly roundup.

Join the channel →