CVE-2025-64460

What it actually does

Django's XML Deserializer calls django.core.serializers.xml_serializer.getInnerText() while walking deserialized XML. That helper has superlinear algorithmic complexity, so a remote, unauthenticated (or low-privilege) client can submit specially nested or highly repetitive XML and force a worker to spend unbounded CPU and RAM assembling text nodes. The result is process-level resource exhaustion and request-handling stall. There is no reported memory-corruption, authentication bypass, or data-disclosure primitive; impact is confined to availability of the process that invokes XML deserialization (including loaddata and any view that calls serializers.deserialize('xml', ...)). Unsupported lines (5.0.x, 4.1.x, 3.2.x and earlier) were not patched and may share the same code path.

Why it matters to the business

Applications that accept Django XML fixtures or otherwise deserialize XML can be knocked offline or forced into costly autoscale events, causing user-facing outages, missed SLAs, and inflated compute bills. The issue is a medium-severity denial of service (CVSS 5.3) with low exploit probability (EPSS ~0.021, flat over 30 days), is not listed in CISA KEV, has no reported ransomware use, and has no public exploit maturity roughly 300 days after publication. Residual risk is highest for internet-facing Django services that still expose XML deserialization; organizations that never deserialize XML are largely unaffected. Django remains a widely deployed web framework, so unpatched instances in production still represent avoidable availability risk.

How an attack unfolds

An attacker first determines that a target Django application deserializes XML—commonly via an upload or import API, an admin loaddata-style workflow, or any code path that feeds untrusted XML into django.core.serializers.deserialize with the xml format. They then send one or more XML documents crafted to maximize work inside getInnerText() (deep or highly repetitive text-node structure). Each request causes a worker to burn CPU and allocate large strings; repeating the request across workers saturates the process pool so legitimate traffic queues or times out. No code execution or data theft is required. Named threat actors and ransomware campaigns have not been publicly tied to this CVE; abuse would look like a targeted application-layer DoS rather than a wormable intrusion.

How to fix it

Upgrade Django to a fixed release: 4.2.27, 5.1.15, or 5.2.9 or later (the upstream fix is commit 6ef1f6fbe33e9882f82dae026b527800ecb78c36). Prefer a supported LTS or current series; do not remain on unevaluated 5.0.x, 4.1.x, or 3.2.x. If XML deserialization is unused, remove those code paths and disallow XML fixtures (for example restrict loaddata to JSON). Until patched, do not expose XML deserialize endpoints to untrusted clients, enforce strict request size and timeout limits, and run workers with memory caps and aggressive restart-on-timeout policies. Rebuild and redeploy all application images that vendor Django rather than only bumping a lockfile on a subset of services.

How to confirm the fix worked

Inventory every runtime and image for the django package and confirm the installed version is >=4.2.27 (4.2 line), >=5.1.15 (5.1 line), or >=5.2.9 (5.2+ line), or that the tree contains commit 6ef1f6fbe33e9882f82dae026b527800ecb78c36. Search application code and dependencies for serializers.deserialize(..., format='xml'), deserialize('xml', ...), and management commands that load XML fixtures. After upgrade, exercise legitimate XML deserialize paths under load and confirm workers no longer exhibit unbounded CPU/RSS growth on previously expensive documents. Verify WAF/body-size and request-timeout controls still reject oversized XML.

Typical attack path

1. Identify a Django application that accepts XML serialized objects (fixture upload, import API, or serializers.deserialize('xml', ...)).
2. Confirm the running Django series is before 4.2.27, 5.1.15, or 5.2.9 (or an unevaluated older series).
3. Submit oversized or highly nested XML designed to inflate getInnerText() CPU and memory use.
4. Repeat or parallelize requests to exhaust WSGI/ASGI workers, request timeouts, and host memory.
5. Observe service degradation (5xx, timeouts, worker restarts) and optionally persist the DoS until operators restart or patch.

How to detect it

This CVE causes resource exhaustion, not a distinct implant, so look for availability artifacts rather than a unique malware family. Review application and web-server logs around XML deserialize and loaddata usage; correlate spikes in worker CPU, RSS, and request latency with POSTs whose Content-Type or path indicates XML. Inspect process crash/OOM killer events for Python/Django workers (gunicorn, uwsgi, uvicorn, daphne) shortly after XML uploads. Check Django request logs for 500/504 on import or fixture endpoints and traceback frames in django.core.serializers.xml_serializer.getInnerText. There are no public KEV/ransomware or named-actor TTPs; treat repeated XML posts that precede worker death as suspected abuse. Retain body-size metrics and WAF XML parser rejects for the same window.

• django.core.serializers.xml_serializer.getInnerText
• django.core.serializers.deserialize
• deserialize('xml'
• format='xml'
• Content-Type: application/xml
• Content-Type: text/xml
• manage.py loaddata
• loaddata
• xml_serializer
• Traceback.*xml_serializer
• gunicorn.*WORKER TIMEOUT
• uwsgi.*HARAKIRI
• Killed process.*python.*(gunicorn|uwsgi|uvicorn|daphne)

What your security team should do

• Patch Django to 4.2.27, 5.1.15, or 5.2.9+ across all services and container images as a planned availability fix, not an emergency KEV-driven outage.
• Inventory and disable unused XML Deserializer / loaddata-xml surfaces so untrusted XML never reaches getInnerText().
• Cap request body size, XML parse depth/entity expansion, and worker timeouts/memory so a single deserialize cannot pin a process.
• Prioritize internet-facing Django apps; internal-only fixture loaders can follow the normal patch cadence.
• Add detection for XML deserialize errors, worker OOM/restarts, and CPU saturation on Django processes; this CVE is not known in ransomware or named APT playbooks.