I'd like to propose a case study on CVE-2025-57833, a SQL injection vulnerability in Django's FilteredRelation feature discovered in September 2025. This vulnerability received a HIGH severity rating of 8.1 from NIST and affects Django versions 4.2 (before 4.2.24), 5.1 (before 5.1.12), and 5.2 (before 5.2.6). This vulnerability arises when FilteredRelation fails to validate column aliases during dictionary expansion via **kwargs passed to QuerySet.annotate() or QuerySet.alias(). An attacker can exploit this by crafting a malicious dictionary that injects arbitrary SQL code.
I think this topic matters because it shows that SQL injection can still sneak into even a well-built, security-minded framework like Django. In this case, The issue isn’t tainted values but dynamic parameters, especially **kwargs—shaping identifiers at API boundaries where ORM safety is assumed. Validate anything that can influence identifiers and design APIs that default to safe, constant names; add static checks to flag dynamic SQL and fuzz/property tests around query builders. In code reviews, explicitly trace untrusted input into SQL structure so these slip-ups are caught long before production.
References:
1). https://docs.djangoproject.com/en/dev/releases/security/
2).https://groups.google.com/g/django-announce
3).https://www.djangoproject.com/weblog/2025/oct/01/security-releases/
4).https://www.djangoproject.com/weblog/2025/sep/03/security-releases/
I'd like to propose a case study on CVE-2025-57833, a SQL injection vulnerability in Django's FilteredRelation feature discovered in September 2025. This vulnerability received a HIGH severity rating of 8.1 from NIST and affects Django versions 4.2 (before 4.2.24), 5.1 (before 5.1.12), and 5.2 (before 5.2.6). This vulnerability arises when FilteredRelation fails to validate column aliases during dictionary expansion via **kwargs passed to QuerySet.annotate() or QuerySet.alias(). An attacker can exploit this by crafting a malicious dictionary that injects arbitrary SQL code.
I think this topic matters because it shows that SQL injection can still sneak into even a well-built, security-minded framework like Django. In this case, The issue isn’t tainted values but dynamic parameters, especially **kwargs—shaping identifiers at API boundaries where ORM safety is assumed. Validate anything that can influence identifiers and design APIs that default to safe, constant names; add static checks to flag dynamic SQL and fuzz/property tests around query builders. In code reviews, explicitly trace untrusted input into SQL structure so these slip-ups are caught long before production.
References:
1). https://docs.djangoproject.com/en/dev/releases/security/
2).https://groups.google.com/g/django-announce
3).https://www.djangoproject.com/weblog/2025/oct/01/security-releases/
4).https://www.djangoproject.com/weblog/2025/sep/03/security-releases/