CVE-2011-4139

What it actually does

The vulnerability stems from the Django framework's improper validation of the HTTP Host header. An attacker can supply a malicious Host header in a request, which the application then uses to generate absolute URLs within the HTTP response. When a caching mechanism, such as a reverse proxy or CDN, is in front of the application, this malicious response can be cached and subsequently served to legitimate users, an attack known as web cache poisoning. This compromises the integrity of the cached web content.

Why it matters to the business

Exploitation can lead to website defacement, redirection of users to malicious phishing sites, or the serving of fraudulent content. This undermines user trust, can lead to financial loss for users who are phished, and causes significant reputational damage to the organization hosting the application. A poisoned cache can persist, affecting all users who request the compromised page until the cache entry expires or is purged.

How an attack unfolds

An unauthenticated remote attacker targets a public-facing Django application that sits behind a web cache. The attacker crafts an HTTP request for a cacheable resource but modifies the `Host` header to a domain they control. The vulnerable Django application receives this request and, when generating absolute URLs for links, redirects, or meta tags in the response, it incorrectly uses the attacker-controlled hostname. The web cache, seeing a request for the legitimate resource, stores the malicious response. When a legitimate user later requests the same resource, the cache serves the poisoned version, causing the user's browser to load content from or be redirected to the attacker's malicious domain.

How to fix it

Upgrade Django to a patched version. For projects on the 1.2.x series, upgrade to version 1.2.7 or later. For projects on the 1.3.x series, upgrade to version 1.3.1 or later. As a defense-in-depth measure, configure the front-end web server (e.g., Nginx, Apache) or load balancer to validate the `Host` header against an explicit allowlist of valid domains, rejecting any requests that do not match.

How to confirm the fix worked

To confirm remediation, check that the installed Django version is 1.2.7+ or 1.3.1+. To test for the vulnerability, use a tool like `curl` to send a request to a cacheable page on the application while specifying a fake `Host` header (e.g., `curl -H 'Host: attacker.com' https://your-app.com/`). Inspect the HTML response for any absolute URLs (in `href`, `src`, `action` attributes) that contain `attacker.com`. If they are present, the application is likely vulnerable. After patching, the same test should show that generated URLs use the correct, configured domain name, not the one from the manipulated header.

Typical attack path

1. Attacker identifies a vulnerable Django application behind a web cache.
2. Attacker sends a request to a cacheable page with a forged `Host` header pointing to an attacker-controlled domain.
3. The Django application generates a response containing absolute URLs built with the forged hostname.
4. The web cache stores the malicious response, associating it with the legitimate page's URL.
5. A legitimate user requests the page and receives the poisoned content from the cache.
6. The user's browser is redirected or loads malicious content, leading to phishing or other attacks.

How to detect it

Review web server (e.g., Nginx, Apache) and CDN access logs. Search for requests where the value of the HTTP `Host` header does not match the expected, legitimate hostname of the server. A high volume of such requests for the same URI from different source IPs could indicate an attempted or successful cache poisoning attack. Correlate these findings with cache logs to check for a `MISS` on the initial request with the bad `Host` header, followed by `HIT`s for subsequent requests from other users to the same URI.

What your security team should do

• Immediately identify all applications using vulnerable Django versions and prioritize them for upgrade to 1.2.7+ or 1.3.1+.
• Audit all public-facing web server and reverse proxy configurations to ensure they are configured to only allow requests with expected `Host` headers.
• Purge all related web caches after deploying the patch to eliminate any potentially poisoned entries.