CVE-2024-21520

What it actually does

The flaw is a reflected or stored cross-site scripting weakness in Django REST framework versions before 3.15.2. The vulnerable `break_long_headers` template filter improperly sanitizes attacker-controlled header-like text before splitting and rejoining it with `<br>` tags, allowing crafted HTML or JavaScript to be rendered in a user’s browser in the context of the affected application. Successful exploitation can let an attacker run script as the victim, read or modify page content, perform actions the victim is authorized to perform, and potentially steal tokens or sensitive data exposed to the browser.

Why it matters to the business

Applications that expose Django REST framework pages or templates using the vulnerable filter may allow attackers to manipulate users’ browser sessions, which can lead to account misuse, data exposure, fraudulent actions, support incidents, and loss of trust. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware use reported, but the issue has been public for a long time and should be remediated through normal patch management, especially for internet-facing administrative or API documentation interfaces.

How an attack unfolds

An attacker identifies an application running a vulnerable version of Django REST framework and finds a page that renders attacker-controlled content through the `break_long_headers` template filter. The attacker supplies a crafted value containing HTML or JavaScript in a field, header, API value, or other displayed text path that reaches the filter. Because the filter does not correctly sanitize the input before adding `<br>` tags, the browser interprets the injected content as markup or script instead of safe text. The payload executes when a user views the affected page, giving the attacker browser-level access within that application session. The attack usually requires a victim to view the maliciously rendered page, but it does not require the attacker to be authenticated if the vulnerable input path is publicly reachable.

How to fix it

Upgrade Django REST framework to version 3.15.2 or later. For source-based deployments of `encode/django-rest-framework`, ensure the fix includes commit `3b41f0124194430da957b119712978fa2266b642` or a later release containing that change. For Debian-packaged affected entries listed in the input, apply vendor updates; the provided fixed package version is `1:52.9.0-1` for Debian 11, 12, and 13 package listings. If immediate upgrade is not possible, avoid rendering untrusted input through `break_long_headers`, apply explicit HTML escaping before display, restrict access to affected browsable/API pages, and enforce a strong Content Security Policy that blocks inline script execution. Treat CSP as a mitigation, not a replacement for upgrading.

How to confirm the fix worked

Confirm dependency versions with package inventory tooling such as `pip show djangorestframework`, `pip freeze`, lockfiles, SBOMs, container image scans, or source repository dependency manifests. The installed Django REST framework version should be 3.15.2 or later, or the source tree should include commit `3b41f0124194430da957b119712978fa2266b642`. Search application templates and custom code for use of `break_long_headers`, especially where values can be influenced by users, request headers, API input, database content, or external integrations. In a non-production test environment, verify that payload-like input such as `<script>alert(1)</script>` is rendered as inert text rather than executable markup. Validate that deployed containers, virtual environments, and build artifacts were rebuilt after dependency updates, not only that source manifests were changed.

Typical attack path

1. Fingerprint the application or its dependencies to determine whether Django REST framework before 3.15.2 is in use.
2. Locate a view, browsable API page, error page, documentation page, or template path that renders attacker-controlled text through `break_long_headers`.
3. Submit crafted input containing HTML or JavaScript payloads designed to survive the filter’s splitting and `<br>` insertion behavior.
4. Cause a victim, administrator, or authenticated user to view the affected page or record.
5. Execute script in the victim’s browser in the security context of the affected application.
6. Use the victim’s session privileges to read visible data, perform state-changing actions, capture exposed tokens, or pivot to additional application functionality.

How to detect it

To determine whether exploitation already occurred, review web server access logs, application request logs, WAF alerts, reverse proxy logs, API gateway logs, and frontend telemetry for requests containing HTML or JavaScript payloads in parameters, headers, JSON fields, form fields, or stored content that may be displayed by Django REST framework pages. Focus on payloads submitted shortly before administrative or authenticated users viewed related pages. Look for encoded or double-encoded XSS strings such as `%3Cscript%3E`, event-handler attributes such as `onerror=`, SVG-based payloads, JavaScript URI payloads, and attempts to break out of HTML contexts. Correlate suspicious requests with subsequent unusual authenticated actions, session reuse from new IP addresses, privilege changes, API key creation, profile changes, or data export activity. Inspect stored records or content repositories for persistent payloads if user-supplied values are saved and later rendered. Browser CSP violation reports, if enabled, may provide high-confidence evidence of attempted or successful script execution.

• break_long_headers
• <script
• </script>
• %3Cscript
• %3C%2Fscript%3E
• javascript:
• onerror=
• onload=
• onclick=
• <img src=x onerror=
• %3Cimg%20src%3Dx%20onerror%3D
• <svg onload=
• %3Csvg%20onload%3D
• alert(1)
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• new Image().src
• <iframe
• %3Ciframe
• <br><script
• &lt;script&gt;

What your security team should do

• Prioritize upgrading all applications using Django REST framework before 3.15.2 to 3.15.2 or later, especially internet-facing applications and administrative interfaces.
• Inventory code paths that render untrusted values in Django REST framework browsable API pages, templates, custom exception handlers, and documentation views.
• Add or strengthen Content Security Policy controls, with particular attention to blocking inline scripts and limiting script sources.
• Review recent web access logs, application logs, WAF events, and frontend error telemetry for XSS payload patterns targeting rendered header or API-display fields.
• If suspicious payloads are found, investigate affected user sessions, privileged account activity, unusual API actions, and any token or credential exposure in browser-accessible contexts.
• Add regression tests to ensure untrusted content passed through display filters is HTML-escaped and does not execute in the browser.
• Ensure dependency scanning detects vulnerable Django REST framework versions in source repositories, CI/CD pipelines, containers, and deployed runtime environments.