CVE-2026-1285

What it actually does

This vulnerability is a remote denial-of-service condition in Django’s HTML-aware truncation logic. When `django.utils.text.Truncator.chars()` or `Truncator.words()` is called with `html=True`, or when templates use `truncatechars_html` or `truncatewords_html`, Django can spend excessive CPU and/or memory processing crafted input that contains a very large number of unmatched HTML closing tags. The issue is network-exploitable, requires no authentication or user interaction, and primarily affects availability; it does not directly provide confidentiality or integrity compromise. Supported affected Django branches are 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28. Older unsupported branches were not fully evaluated and should be treated as potentially affected if they use the vulnerable truncation paths.

Why it matters to the business

Public-facing Django applications that render attacker-controlled text through HTML truncation filters may be slowed down or made unavailable by relatively simple malicious requests. The most likely consequence is service degradation, worker exhaustion, request timeouts, increased infrastructure cost from autoscaling, and potential outage of pages that display user-supplied HTML-like content such as comments, profiles, messages, descriptions, feeds, or imported content. The CVSS availability impact is high, but current public exploitation signals are limited: EPSS is low at 0.00993, no known CISA KEV listing is present, and no ransomware association is reported. Because this was published over six months ago, unpatched internet-facing deployments should still be prioritized, especially where Django is widely reused across business-critical web services or container images.

How an attack unfolds

An attacker first identifies a Django-backed endpoint that accepts or stores text later rendered with `truncatechars_html`, `truncatewords_html`, or `Truncator(...).chars()/words(..., html=True)`. They then submit or request content containing an intentionally large sequence of unmatched HTML end tags, such as repeated closing tags without corresponding open tags. When the vulnerable view or template renders that content, Django’s HTML-aware truncation algorithm performs excessive work trying to process malformed tag structure. Repeating the request, or triggering rendering of stored malicious content by other users, can tie up application workers and cause slow responses, 5xx errors, queue buildup, or full service unavailability. No code execution or data theft is expected from the flaw itself, but outage conditions may compound other operational risks.

How to fix it

Upgrade Django to a fixed supported release: Django 6.0.2 or later, Django 5.2.11 or later, or Django 4.2.28 or later. If consuming Django from source, ensure the fix commit `ba00558ddac694d92b05d12ecd2a5b7fcc1de025` or a later commit is present. For Chainguard affected packages, upgrade `beats-fips-7`, `metricbeat-fips-7`, `auditbeat-fips-7`, `filebeat-fips-7`, `heartbeat-fips-7`, and `heartbeat-fips-7-oci-entrypoint` to `7.17.29-r7` or later where applicable. Unsupported Django branches such as 5.0.x, 4.1.x, and 3.2.x should be upgraded to a supported fixed branch rather than assumed safe. As temporary mitigation, avoid applying `truncatechars_html` or `truncatewords_html` to untrusted input, strip or normalize HTML before truncation, cap maximum input length before rendering, and enforce request/body size limits and rate limiting on endpoints that accept rich text.

How to confirm the fix worked

Confirm package versions in application dependency manifests, lockfiles, containers, and runtime environments show Django 6.0.2+, 5.2.11+, or 4.2.28+. For source-based deployments, verify the presence of commit `ba00558ddac694d92b05d12ecd2a5b7fcc1de025` or equivalent patched code. Search application templates and code for use of `truncatechars_html`, `truncatewords_html`, `Truncator.chars(..., html=True)`, and `Truncator.words(..., html=True)` to identify exposed rendering paths. In a non-production test environment, submit a bounded malformed HTML payload with many unmatched closing tags to affected rendering paths and confirm response time remains stable after upgrade. Validate that web application firewalls, reverse proxies, and application settings enforce practical request size and rate limits. Rebuild and redeploy containers to ensure patched dependencies are actually present at runtime, not only in source control.

Typical attack path

1. Find a Django application page or API that displays user-controlled text with HTML-aware truncation.
2. Craft input containing a very large number of unmatched HTML closing tags.
3. Submit the crafted input directly in a request or store it in content that will later be rendered.
4. Trigger the vulnerable rendering path using `truncatechars_html`, `truncatewords_html`, or `Truncator` with `html=True`.
5. Repeat requests or cause repeated rendering of the stored payload to consume application CPU/workers.
6. Observe degraded response times, request timeouts, elevated 5xx errors, or application unavailability.

How to detect it

To determine whether exploitation has already occurred, correlate web access logs, application logs, reverse proxy logs, WAF events, APM traces, and host/container metrics. Look for requests with parameters, form bodies, JSON fields, or stored content containing unusually high counts of repeated HTML closing tags, especially sequences like `</a></a></a>`, `</div></div></div>`, or many percent-encoded closing tags such as `%3C%2Fdiv%3E`. Review time windows with elevated CPU, request latency, worker exhaustion, application restarts, process kills, autoscaling events, 499/500/502/503/504 responses, or upstream timeout messages. Check endpoints that create or display user-generated rich text, comments, descriptions, messages, feeds, profile fields, support tickets, CMS content, or imported HTML. Because the vulnerability is a denial-of-service issue, evidence is more likely to appear as performance anomalies and malformed request payloads than as durable files or persistence artifacts. If request bodies are not logged, use WAF/body inspection telemetry, application error traces, APM slow transaction samples, and database/content review for records containing excessive unmatched closing tags.

• truncatechars_html
• truncatewords_html
• html=True
• </div></div></div>
• </span></span></span>
• </p></p></p>
• </a></a></a>
• %3C%2Fdiv%3E%3C%2Fdiv%3E%3C%2Fdiv%3E
• %3C%2Fspan%3E%3C%2Fspan%3E%3C%2Fspan%3E
• %3C%2Fp%3E%3C%2Fp%3E%3C%2Fp%3E
• %3C%2Fa%3E%3C%2Fa%3E%3C%2Fa%3E
• upstream timed out
• worker timeout
• request timed out
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout
• ba00558ddac694d92b05d12ecd2a5b7fcc1de025

What your security team should do

• Inventory Django applications and container images, prioritizing internet-facing services and pages that render user-generated content.
• Upgrade all supported Django deployments to 6.0.2+, 5.2.11+, or 4.2.28+; migrate unsupported Django branches to a supported fixed branch.
• Search codebases for `truncatechars_html`, `truncatewords_html`, and `Truncator` calls using `html=True`, and review whether untrusted input can reach those paths.
• Apply compensating controls while patching: request-size limits, body-size limits, rate limiting, worker timeout controls, and input length caps for rich-text fields.
• Review application and proxy logs since publication for unusual bursts of requests containing repeated HTML closing tags and correlated spikes in latency, CPU, worker restarts, or 5xx responses.
• Update base images and Chainguard packages to fixed versions such as `7.17.29-r7` where applicable, then redeploy rather than relying on in-place dependency updates.
• Add regression tests for malformed HTML truncation to prevent reintroduction of expensive parsing behavior in custom template filters or wrappers.