CVE-2025-59681 is a high severity (CVSS 7.1) SQL injection in Django column aliases for QuerySet.annotate, alias, aggregate and extra on MySQL and MariaDB. Upgrade to Django 4.2.25, 5.1.13 or 5.2.7. The sections below cover who is affected, how to check, and what to do now.
What's affected
From the Django security release announcement of 1 October 2025:
- Django 4.2 before 4.2.25: fixed in 4.2.25
- Django 5.1 before 5.1.13: fixed in 5.1.13
- Django 5.2 before 5.2.7: fixed in 5.2.7
The Django project also patched its main and 6.0 alpha branches. The issue applies when the database is MySQL or MariaDB. Django rates this as high severity under its own policy.
How to check if you're exposed
Check the installed version and database backend:
python -m django --version
pip show django
pip freeze | grep -i '^django=='
Then search your code for the four methods called with a dictionary expanded into keyword arguments, for example a call such as annotate(**something), where the dictionary keys can come from a request. That is the pattern the advisory describes.
grep -rnE "(annotate|alias|aggregate|extra)\(\*\*" --include=*.py .
What to do now
- Upgrade to Django 4.2.25, 5.1.13 or 5.2.7, depending on your series.
- Run your test suite and deploy.
- Search for dictionary expansion into annotate, alias, aggregate and extra, and make sure the keys never come from user input.
- If you use MySQL or MariaDB, prioritise those services.
- Pin Django in your lockfile so a rebuild cannot pull an older release.
Why it matters
The record maps this to CWE-89, SQL injection. The unusual part is where it happens. The risky value is not the data in a query but the column alias, the label given to a computed column. If an application builds that dictionary of aliases from user supplied keys and expands it into the call, a crafted key can alter the SQL on MySQL and MariaDB.
The score is 7.1 and not higher because the vector needs high attack complexity and a low privileged account. It is not on the CISA KEV list. The takeaway is a good habit for any framework: names that end up in SQL, such as aliases, columns and sort keys, need an allow list, because parameter binding does not protect them.
SQL injection happens when input reaches a database query as part of its structure instead of as plain data. The reliable defence is the same everywhere: parameterised queries or prepared statements, and no string building for anything a user can influence. Input validation helps, but it is a second line, not the first.
If you find injectable code in your own applications, treat the fix as two jobs. Change the query so the value is bound as a parameter, and check the database account the application uses. An account that can only read the tables it needs turns a bad bug into a smaller one.
Safeguard can help you find this one in your own software. The free in-browser dependency scan at gold.safeguard.sh/scan reads your manifest or lockfile and shows which known vulnerabilities your declared dependencies carry, including transitive ones. Reachability analysis then helps you separate the places where your code actually calls the affected component from the places where it only sits in the tree, which makes it easier to decide what to patch first.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which Django versions fix CVE-2025-59681?
4.2.25, 5.1.13 and 5.2.7.
Does it affect PostgreSQL or SQLite?
The advisory describes it for MySQL and MariaDB only.
Sources
- Django security releases, 1 October 2025
- NVD record data
Last reviewed: 18 October 2026.
