CVE-2015-5963

What it actually does

The flaw is a network-reachable denial-of-service condition in Django's session handling. In affected Django releases, repeated unauthenticated requests to the built-in logout view can cause creation of empty session records even when no meaningful authenticated session exists. An attacker can automate large volumes of logout requests to consume backing session-store capacity, increase database/cache/storage load, or trigger removal/turnover of legitimate session records depending on the session backend and application behavior. The impact is availability degradation rather than code execution or data disclosure.

Why it matters to the business

Successful exploitation can make Django-backed applications slow, unstable, or unavailable by exhausting session storage or overloading the session backend. This may disrupt user logins, terminate active sessions, increase infrastructure costs, and cause operational incidents for public-facing services. The issue is old and not listed in CISA KEV, and no mature public exploit is indicated in the provided data, but it is remotely reachable, low-complexity, unauthenticated, and has a non-trivial EPSS score, so internet-exposed legacy Django deployments should still be remediated.

How an attack unfolds

An attacker identifies an application running an affected Django version that exposes a logout route backed by django.contrib.auth.views.logout and uses contrib.sessions.middleware.SessionMiddleware. The attacker then sends a high volume of HTTP requests to that logout endpoint, often from scripts, botnets, proxies, or rotating IP addresses. Each request can trigger creation of an empty session entry rather than simply returning without session persistence. Over time, the session backend accumulates unnecessary records or experiences churn, resulting in storage growth, database/cache pressure, lock contention, cleanup overhead, or removal of useful session records. The application may then exhibit slow responses, login failures, session instability, elevated error rates, or full service degradation.

How to fix it

Upgrade Django to a fixed release: Django 1.8.x should be upgraded to 1.8.4 or later, Django 1.7.x to 1.7.10 or later, and Django 1.4.x to 1.4.22 or later. Prefer upgrading to a currently supported Django long-term-support release because the affected branches are obsolete. For operating-system packaged deployments, apply the relevant Canonical Ubuntu, Oracle Solaris, or vendor package updates. If immediate upgrade is not possible, apply compensating controls: rate-limit unauthenticated requests to logout endpoints, require appropriate HTTP methods and CSRF protections where applicable, block abusive IPs or user agents at the edge, tune session cleanup jobs, monitor session backend capacity, and consider moving session storage to a backend with quotas and operational safeguards. These mitigations reduce exposure but should not replace patching.

How to confirm the fix worked

Confirm the installed Django version is not in the affected range and is at or above the fixed version for its branch. Validate through package managers, dependency manifests, virtual environments, container images, and runtime checks such as importing Django and printing django.get_version(). Review application routing to identify logout views that use the affected Django auth logout implementation. In a non-production test environment, send repeated unauthenticated requests to logout endpoints and verify that empty sessions are not created and session-store growth does not occur. Also verify that edge rate limits and WAF/API gateway controls apply to logout routes and that session cleanup/expiry tasks are operating normally.

Typical attack path

1. Discover a public Django application and identify likely logout URLs such as /logout/ or /accounts/logout/.
2. Confirm the endpoint is reachable without authentication or with trivial session state.
3. Send automated, repeated HTTP GET or POST requests to the logout endpoint at high volume.
4. Force the application to create many empty session records through the vulnerable session middleware/logout interaction.
5. Exhaust or overload the configured session backend, such as database, cache, or file-based session storage.
6. Cause degraded performance, failed logins, unstable user sessions, or application unavailability.

How to detect it

To determine whether this was already exploited, review web server, reverse proxy, CDN, WAF, and application access logs for unusual spikes of requests to logout endpoints, particularly unauthenticated requests, requests without prior navigation, requests lacking normal referrers, or high request rates from a small set of IPs, autonomous systems, proxies, cloud hosts, or repetitive user agents. Correlate these spikes with session backend telemetry, including sudden growth in stored sessions, increased session write operations, cleanup job duration, database/cache latency, storage utilization, lock waits, eviction events, and application 5xx errors. Application logs may show increased activity around Django auth logout handling or session creation during periods without corresponding user activity. Forensic review should focus on time windows where logout request volume, session-store growth, and application degradation align. Because this vulnerability does not provide code execution, durable host-level IOCs are not expected; detection is primarily behavioral and log-volume based.

• django.contrib.auth.views.logout
• django.contrib.sessions.middleware.SessionMiddleware
• GET /logout
• POST /logout
• GET /logout/
• POST /logout/
• GET /accounts/logout
• POST /accounts/logout
• GET /accounts/logout/
• POST /accounts/logout/
• django/contrib/sessions/middleware.py
• django/contrib/auth/views.py

What your security team should do

• Inventory all applications and containers running Django, especially legacy 1.4.x, 1.7.x, and 1.8.x deployments exposed to the internet.
• Upgrade affected Django installations to fixed versions or, preferably, to a supported Django LTS release.
• Prioritize public-facing applications with database-backed, file-backed, or capacity-constrained session storage.
• Add or verify rate limiting for logout endpoints and other unauthenticated session-touching routes.
• Monitor session backend size, write rate, cleanup failures, response latency, and HTTP 5xx/429 rates for signs of abuse.
• Search historical web access logs for high-volume unauthenticated requests to logout paths from single IPs, distributed IP ranges, or unusual user agents.
• Ensure incident runbooks include session-store exhaustion scenarios and safe cleanup procedures for empty or stale session artifacts.
• If using vendor-packaged Django on Ubuntu or Solaris, verify that the appropriate OS security update has been applied rather than relying only on application dependency files.