CVE-2011-4139: Django Cache Poisoning Vulnerability

django Updated 02 Oct 2025

Summary

19/10/2011
Yes i
High
7.5

CVE-2011-4139: Django before 1.2.7 and 1.3.x before 1.3.1 uses a request's HTTP Host header to construct a full URL in certain circumstances, which allows remote attackers to conduct cache poisoning attacks via a crafted request. 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

The same CVE-2011-4139 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

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.

Sponsored Devnack Penetration testing for web, API and mobile Manual testing by engineers who build software, not an auditor's checklist. Trusted by teams at Swift and Google Talk to Devnack

Background

Django is a popular Python web framework used for developing web applications. It provides a high-level API for handling web requests, managing databases, and rendering templates. The framework is widely adopted and known for its security features. However, prior to version 1.2.7 and 1.3.x before 1.3.1, Django was vulnerable to a cache poisoning attack.

Vulnerability Detail

The vulnerability in Django arises from its use of the HTTP Host header to construct a full URL in certain scenarios. This behavior can be exploited by remote attackers to conduct cache poisoning attacks. By crafting a malicious request with a specially crafted Host header, an attacker can manipulate the cache and potentially trick the application into serving incorrect or malicious content to users. This can lead to various security issues, including the injection of malicious code or the disclosure of sensitive information.

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 temporary workaround is to implement a custom middleware that sanitizes the Host header before it is used to construct URLs. This can involve validating the Host header against a whitelist of allowed values or performing additional checks to ensure its integrity. Here is an example of a custom middleware that sanitizes the Host header:

from django.http import HttpResponseBadRequest

class HostHeaderSanitizationMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        host = request.META.get('HTTP_HOST', '')
        # Perform sanitization checks here
        if not is_valid_host(host):
            return HttpResponseBadRequest('Invalid Host header')
        return self.get_response(request)

def is_valid_host(host):
    # Implement custom validation logic here
    return True

Conclusion

The cache poisoning vulnerability in Django versions prior to 1.2.7 and 1.3.x before 1.3.1 can be exploited by remote attackers to manipulate the application's cache and potentially serve malicious content. To mitigate this risk, it is recommended to upgrade Django to the patched versions or apply the provided workaround. For further assistance or support in vulnerability remediation, please contact DevNack.com.

See every vulnerability recorded for django →

Share this vulnerability

FAQ

The vulnerability allows remote attackers to conduct cache poisoning attacks, potentially leading to the injection of malicious code or the disclosure of sensitive information.

You can use the Vulert Playground at Vulert Scanner to check if your application is affected by this vulnerability. Simply provide your Pipfile.lock file, and Vulert will analyze it for any known vulnerabilities, including this cache poisoning issue.

While specific exploits targeting this vulnerability may exist, there are no publicly known exploits at the time of this advisory. However, it is crucial to address the vulnerability promptly to mitigate the risk of potential attacks.

While applying the workaround can provide temporary protection, it is strongly recommended to upgrade Django to the patched versions as soon as possible. Upgrading ensures that your application benefits from the latest security fixes and reduces the reliance on custom mitigations.

You can find more information about this vulnerability, including the technical details and the patch, in the Django advisory PYSEC-2011-4 available at https://github.com/pypa/advisory-database/blob/main/vulns/django/PYSEC-2011-4.yaml.

Related vulnerabilities

Recent vulnerabilities recorded for django.

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 →
Help improve this record
Report an issue or send feedback