CVE-2015-2316

What it actually does

The strip_tags utility enters an infinite loop when processing an attacker-controlled input string of increased length under certain Python versions, consuming CPU and preventing further request handling.

Why it matters to the business

Web applications become unresponsive or crash under load, causing service outages and potential loss of revenue or user trust; the vulnerability is nine years old with no active exploitation campaigns reported.

How an attack unfolds

An unauthenticated attacker identifies a Django view that invokes strip_tags on user-supplied data and submits a single HTTP request containing a long, specially formatted string that triggers the loop.

How to fix it

Upgrade Django to 1.6.11, 1.7.7, or 1.8c1 (or newer maintained releases) and restart affected services; where immediate patching is impossible, wrap calls to strip_tags with timeouts or input-length limits.

How to confirm the fix worked

Verify the installed Django version meets or exceeds the fixed releases, then execute unit tests that feed progressively longer strings to strip_tags and confirm the function returns in bounded time.

Typical attack path

1. Locate an HTTP endpoint that passes request data to strip_tags
2. Craft an input string long enough to trigger the infinite loop under the affected Python version
3. Send the request to the endpoint
4. Observe the target process consuming 100% CPU and ceasing to respond to subsequent requests

How to detect it

Review web-server and application logs for requests with unusually long query or body parameters followed by worker processes showing sustained high CPU; correlate with WSGI or uWSGI request timeout entries.

What your security team should do

• Apply the listed Django upgrades within 30 days
• Add input-size validation around any remaining calls to strip_tags
• Monitor application CPU and request latency for sudden spikes
• Remove or replace deprecated strip_tags usage in new code