Django’s security team just released two coordinated updates: 5.2.9 and 4.2.27. They fix a SQL injection bug and a denial-of-service issue, both serious, both affecting core Django internals.

If you run a Django app, especially one on PostgreSQL or anything using XML deserialization, this isn’t one to skip.

Here’s what changed, and what it means for your project.

The vulnerabilities

SQL Injection in PostgreSQL aliases

CVE‑2025‑13372 affects the way FilteredRelation, annotate(), and alias() interact with PostgreSQL when used with dynamically built **kwargs. If a malicious value makes it into an alias name, SQL can be injected, even without authentication.

This is a high-severity issue if you use dynamic annotations or custom filtering logic.

DoS via XML deserialization

CVE‑2025‑64460 is a denial-of-service vulnerability in Django’s XML deserializer. Crafted XML input can exploit inefficient text-node handling, consuming excessive CPU or memory, and potentially crashing your app under load.

What Django released

The Django team patched both issues in:

• - 5.2.9: latest in the 5.x line

• - 4.2.27: backported for the 4.2 LTS

If you’re on either version track, upgrading is the fastest way to close the vulnerability window.

What this means for your projects

If your project meets any of these criteria, treat this update as urgent:

• - Uses PostgreSQL with custom ORM logic or dynamic annotations

• - Accepts XML input (even from admin tools, migrations, or legacy integrations)

• - Runs in a production environment where service disruption has real costs

This isn’t just about bugs, it’s about risk exposure. If your stack can be crashed or manipulated by external input, you need to know, and fix it.

What we’re doing at DWS

At DWS, we stick to the LTS versions for stability, but we never ignore security releases.

We’ve already:

• - Upgraded all affected client projects to 4.2.27 or 5.2.9

• - Audited ORM patterns that rely on dynamic alias() or FilteredRelation

• - Flagged XML parsing in legacy tools and admin scripts

• - Tightened CI rules to surface high-priority CVEs earlier

This is part of how we work: stay stable, but stay patched.

What you should do now

1. - Check your Django version.
   If you’re running anything earlier than 4.2.27 or 5.2.9, plan to update now.

2. - Review how you use PostgreSQL + ORM helpers.
   If you use advanced annotation or aliasing patterns, audit those places first.

3. - Trace any XML input.
   If your app accepts, parses, or deserializes XML, validate it or isolate the handler.

4. - Treat security releases as operational, not optional.
   Even LTS versions need maintenance. Security fixes like this are why.

The deeper lesson

Frameworks evolve. But no matter how battle-tested they are, security issues will surface, especially in complex, underused corners of the API.

This round of CVEs is a reminder that:

• - Long-term support doesn’t mean “hands-off”

• - Even trusted APIs (like annotate() or deserialize()) can open risks when used dynamically

• - And the longer you wait to patch, the harder it gets

If you need help reviewing your Django setup, or you’re not sure how deep your dependency stack goes, we can help.

👉 Book a call and let’s make sure your code is secure, up-to-date, and built for the long run.