CVE-2025-48432

What it actually does

This flaw affects Django's internal HTTP response logging in versions 5.2 before 5.2.2, 5.1 before 5.1.10, and 4.2 before 4.2.22. Django failed to properly escape or sanitize request.path before writing it to logs. A remote attacker can send crafted URLs containing control characters, encoded newlines, carriage returns, terminal escape sequences, or log-format-looking text so that the resulting log entry is misleading when viewed in terminals or consumed by log processors. The issue does not directly provide code execution, authentication bypass, or data access, but it can undermine log integrity, confuse investigations, spoof events, or interfere with downstream monitoring and alerting systems.

Why it matters to the business

The main risk is loss of trust in application logs. Attackers may be able to hide malicious activity, create fake log entries, disrupt automated log parsing, or mislead incident responders. This can increase investigation time, reduce confidence in audit trails, and cause false positives or false negatives in monitoring systems. The EPSS score is low and the issue is not listed in CISA KEV, so broad active exploitation is not currently indicated; however, Django is widely used in web applications, and internet-facing services should still be upgraded during normal patch cycles.

How an attack unfolds

An attacker identifies a web application running an affected Django version and sends HTTP requests with specially crafted paths. The path may include URL-encoded carriage returns and line feeds, terminal control sequences, or strings that resemble legitimate log records. When Django logs the HTTP response, the unescaped path is written into the log output. If logs are viewed directly in a terminal, forwarded to a SIEM, parsed by a pipeline, or used in audit workflows, the injected content may appear as separate log lines, alter visual output, or create forged entries. An attacker can use this to obscure probing, make it appear that different requests occurred, inject misleading status codes or source addresses into downstream views, or degrade the reliability of detection and forensic review.

How to fix it

Upgrade Django to a fixed release: 5.2.2 or later for the 5.2 branch, 5.1.10 or later for the 5.1 branch, and 4.2.22 or later for the 4.2 LTS branch. If consuming Django directly from source, ensure the code includes the upstream fix commit 2285698fc1e41ff34dffcc0625528a8db7318a18 or a later equivalent commit. Rebuild and redeploy applications after dependency updates, and restart application processes so the patched Django version is loaded. As defense in depth, configure web servers, WAFs, API gateways, or application middleware to reject or normalize URL paths containing raw or encoded control characters. Ensure log pipelines treat request paths as data, escape control characters before display, and avoid parsing untrusted path content as structured log fields. The supplied affected product list also references linux-oem-5.14 for Ubuntu 20.04 LTS with a fixed version of 5.14.0-1049.56; validate this against operating system vendor advisories because the described vulnerability is specific to Django logging behavior.

How to confirm the fix worked

Confirm the installed Django version in each application runtime using package manifests, lockfiles, container images, and runtime checks such as `python -m django --version` or package manager output. Validate that deployed versions are Django 5.2.2 or later, 5.1.10 or later, or 4.2.22 or later as applicable. For source-based deployments, verify the patched commit 2285698fc1e41ff34dffcc0625528a8db7318a18 or a later commit is present. Review dependency lockfiles and software composition analysis results to ensure vulnerable transitive copies are not still packaged into images or virtual environments. In a non-production test environment, send benign requests containing encoded newline or escape characters in the URL path and confirm logs escape or safely represent the path rather than creating new lines, terminal effects, or forged records. Also confirm SIEM parsers and log processors do not treat path content as trusted log metadata.

Typical attack path

1. Identify a Django-based web application exposed over HTTP or HTTPS.
2. Send requests with crafted URL paths containing encoded control characters such as carriage returns, line feeds, or terminal escape sequences.
3. Trigger application response logging for those requests.
4. Rely on Django's vulnerable logging behavior to write the unescaped request path into application or server logs.
5. Cause forged, misleading, visually altered, or parser-confusing log output in terminals, SIEMs, or log-processing systems.
6. Use the corrupted log trail to complicate monitoring, alert triage, or incident response.

How to detect it

To determine whether this was already exploited, review logs that captured HTTP request paths while affected Django versions were running. Key sources include Django application logs, web server access logs, reverse proxy logs, load balancer logs, WAF events, CDN logs, container stdout/stderr, centralized logging platforms, and SIEM-normalized web events. Search for URL paths containing raw or percent-encoded control characters, especially carriage returns, line feeds, tabs, null bytes, escape characters, and ANSI terminal control sequences. Look for log records that appear split across multiple lines, contain unexpected embedded timestamps or log levels, include visually corrupted terminal output, or have mismatched fields after parsing. Compare the same request across multiple telemetry layers: if a reverse proxy records one request but the application or SIEM shows multiple apparent records, forged fields, or altered message structure, treat the application log as potentially manipulated. Investigators should also review alert gaps around suspicious crafted-path requests because the purpose of exploitation may be to confuse detections rather than to produce a direct compromise artifact.

• %0a
• %0A
• %0d
• %0D
• %0d%0a
• %0D%0A
• %1b
• %1B
• %09
• %00
• \x1b
• \033
• \u001b
• %5B0m
• %5B31m
• %5B32m
• %5B2J
• %5BH
• %1b%5B
• %E2%80%AE

What your security team should do

• Inventory Django applications and prioritize internet-facing services and services whose logs feed security monitoring or audit workflows.
• Upgrade affected Django branches to 5.2.2, 5.1.10, or 4.2.22 or later, and redeploy all dependent applications and containers.
• Search recent access, application, reverse proxy, and WAF logs for encoded control characters in URL paths, especially `%0a`, `%0d`, `%1b`, `%09`, and ANSI escape patterns.
• Harden log pipelines so untrusted request fields are escaped before display and cannot create new structured fields or records.
• Add WAF or gateway rules to block URL paths containing raw or encoded carriage returns, line feeds, null bytes, or terminal escape sequences where application behavior does not require them.
• Review detection rules that rely heavily on Django application logs for possible parser confusion or forged events during the vulnerable period.
• Treat suspicious log entries around crafted-path requests as potentially attacker-controlled and corroborate with reverse proxy, load balancer, EDR, and network telemetry.