CVE-2015-5143

What it actually does

The flaw allows an unauthenticated remote client to force excessive session-store growth by repeatedly sending requests that cause the application to create or retain many distinct session keys. In vulnerable Django session backends, each unique session key can consume persistent storage, cache capacity, database rows, file-system space, or backend memory. The result is an availability impact: session infrastructure can become full, slow, locked, or error-prone, causing degraded application performance or outage. The issue does not directly provide code execution, data disclosure, or privilege escalation.

Why it matters to the business

A public-facing application using an affected session backend can be made unavailable with relatively simple network traffic, potentially disrupting customer access, logins, transactions, administrative workflows, and other web operations. Although this issue is not listed in CISA KEV, is not known to be associated with ransomware, and has no reported mature public exploitation in the provided data, it is old and should generally already be remediated in supported software baselines. The EPSS value indicates some likelihood of exploitation activity relative to many vulnerabilities, and internet-exposed applications with stateful session handling are the primary operational concern.

How an attack unfolds

An attacker identifies a web application that uses a vulnerable Django session backend or downstream product version with the vulnerable behavior. The attacker then automates repeated HTTP requests while varying or forcing unique session identifiers so that the server treats each request as a distinct session context. Because the vulnerable backend does not adequately constrain or clean up this pattern, the session store accumulates large numbers of session records or objects. As storage, cache, database, or file-system resources are consumed, legitimate users begin experiencing slow responses, failed logins, server errors, or full outage. The attack can be performed remotely without authentication and does not require stealing valid user sessions.

How to fix it

Upgrade affected Django deployments to fixed or supported versions: Django 1.4.21 or later for the 1.4 line, Django 1.7.9 or later for the 1.7 line, and Django 1.8.3 or later for the 1.8 line. Django 1.5.x and 1.6.x are historically affected and should be migrated to a supported fixed release rather than retained. For the supplied affected package metadata, update b2evolution/b2evolution GIT to a revision containing commit e35f7c195d8c1103d2d981a48cda5ab45ecac48a or a later trusted release that includes the fix. As compensating controls, enforce rate limits on unauthenticated requests, limit requests that create new sessions, configure session expiration and cleanup jobs, monitor and cap session-store growth, ensure adequate backend capacity, and place application-layer DoS protections in front of exposed services.

How to confirm the fix worked

Confirm that the deployed framework or package version includes the fixed Django session backend behavior or the listed downstream fixed commit. Review dependency manifests, lockfiles, container images, and deployed package metadata rather than relying only on source repositories. In a non-production test environment, simulate repeated requests with unique or absent session cookies and verify that session-store growth is bounded and does not cause persistent resource exhaustion. Confirm that scheduled session cleanup is running successfully, session expiration is configured appropriately, and monitoring alerts trigger on abnormal session-store growth, disk consumption, cache pressure, database growth, and elevated 5xx responses. For b2evolution/b2evolution GIT deployments, verify that commit e35f7c195d8c1103d2d981a48cda5ab45ecac48a or a later commit containing the fix is present in the deployed code.

Typical attack path

1. Discover an internet-accessible web application using an affected Django session backend or affected downstream package.
2. Send repeated HTTP requests to session-creating endpoints such as landing pages, login pages, or application routes that initialize sessions.
3. Vary the session identifier or omit/replay cookies in a way that causes the application to allocate many unique sessions.
4. Continue the request stream until the session backend consumes excessive database, cache, memory, or disk resources.
5. Cause legitimate user requests to fail due to exhausted session storage, backend timeouts, lock contention, or application errors.

How to detect it

To determine whether exploitation has already occurred, review web access logs, reverse proxy logs, WAF/CDN logs, application logs, session backend logs, cache/database metrics, and host resource telemetry for abnormal session creation patterns. Look for bursts of unauthenticated HTTP requests from one or many IP addresses where each request presents a different session cookie value, omits cookies but receives new session cookies, or repeatedly targets routes that initialize sessions. Correlate these bursts with rapid growth in session storage, cache pressure, disk-space consumption, backend latency, increased lock waits, elevated 500/503 responses, and application errors indicating storage exhaustion. Because no named threat actors or KEV exploitation are provided, prioritize behavioral detection over actor-specific indicators. Useful retrospective queries include counting distinct session cookie values per source IP and per time window, identifying user agents generating unusually high session churn, and comparing session-store growth against normal traffic baselines.

• Cookie: sessionid=
• Set-Cookie: sessionid=
• sessionid=
• OperationalError: database or disk is full
• OSError: [Errno 28] No space left on device
• No space left on device
• database or disk is full
• HTTP/1.1" 500
• HTTP/1.1" 503
• Service Unavailable
• Internal Server Error
• Session data corrupted
• SessionStore
• django.contrib.sessions

What your security team should do

• Inventory internet-facing applications using Django or downstream packages that rely on Django-style session backends, and prioritize those that allow unauthenticated session creation.
• Upgrade vulnerable Django versions and affected downstream package builds to fixed releases or commits; retire unsupported Django 1.5.x and 1.6.x deployments.
• Add or tune rate limiting, bot mitigation, and WAF/CDN controls for high-volume unauthenticated requests and abnormal cookie churn.
• Set alerts for rapid session-store growth, backend storage exhaustion, cache eviction spikes, database growth anomalies, and increases in HTTP 500/503 errors.
• Review historical access logs for high request volumes from single sources or distributed sources with many unique session cookies.
• Ensure session cleanup tasks are enabled, scheduled, monitored, and completing successfully.
• Capacity-test session backends under abusive session-creation patterns after patching to verify resilience.