Case-Study proposal: Django Filtered Relation, "SQL-Injection - CVE-2025-57833"

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/

No repository files, tests, or entry points are identified. Start by reviewing the linked Django security advisories and confirm the repository's expected case-study format before drafting. Done should be a case study covering CVE-2025-57833 and its secure-coding lessons, but the issue does not define acceptance criteria.