1. Introduction

Hi everyone, today we will take a closer look at a recently disclosed Django vulnerability that demonstrates how a single coding mistake can completely undermine the security of a web application. The vulnerability is tracked as CVE 2025 64459 and affects Django's QuerySet API when developers misuse user input with internal ORM mechanisms.

This TryHackMe room provides a hands-on demonstration of the issue. You will see how a vulnerable Django view processes query parameters, how attackers can tamper with internal ORM controls, and how the exploitation leads to full data exposure. This write up covers both the technical explanation and a full reproduction of the attack paths used in the room.

2. What is Django

Django is a Python web framework widely used in enterprise environments, SaaS platforms, and high traffic websites. One of its strongest features is the built-in Object Relational Mapping system, often referred to as the ORM. Instead of writing raw SQL queries, developers interact with the database through Python functions and classes.

For example:

User.objects.filter(is_active=True)

The ORM translates this into SQL automatically. Developers can combine multiple conditions by chaining filters, or by using Django's Q objects, which allow complex expressions that resemble logical operators.

A basic Q object example:

from django.db.models import Q
User.objects.filter(Q(is_staff=True) | Q(is_superuser=True))

This would produce a query similar to:

SELECT * FROM user WHERE is_staff = true OR is_superuser = true;

Django normally sanitizes parameters and prevents unsafe SQL injection. However, this protection is built on the assumption that internal ORM parameters are never exposed to users. The vulnerability occurs when that assumption is broken by the developer.

3. How the Vulnerability Occurred

The vulnerable pattern appears when a developer directly takes user input and passes it to Django's Q(**kwargs) constructor. Consider this code:

query_params = dict(request.GET.items())
q_filter = Q(**query_params)
posts = Post.objects.filter(q_filter)

At first glance, this approach looks convenient. It allows users to filter posts by passing arbitrary query parameters like ?title=Hello or ?author=John.

The problem is that Django's ORM accepts several internal magic keys. These are intended only for internal use and should never be set by external users. Before the patch, Django allowed two of them through:

1. _connector Controls how conditions are combined. Valid values are AND or OR. If an attacker injects OR 1=1 OR, the underlying SQL logic becomes insecure.
2. _negated A boolean flag that reverses the meaning of the entire query. When set to True, a filter intended to match certain rows instead returns all rows that do not match.

The vulnerability arises because the developer placed user input directly inside Q(**user_data), which means an attacker can do:

?_connector=OR 1=1 OR

This creates a query that Django interprets as a legitimate connector change and leads to SQL conditions that always evaluate to true.

Why this is dangerous

When _connector or _negated are manipulated:

• Filters meant to restrict data no longer behave as intended.
• Queries that normally return a small subset now return entire tables.
• Access controls relying on ORM logic can be bypassed.
• Sensitive or unpublished records become readable.

The official patch modifies the QuerySet backend to reject any attempt to set _connector or _negated from external input.

4. Exploiting the TryHackMe Room

The TryHackMe challenge recreates a simplified but realistic vulnerable Django application. The backend code includes:

query_params = dict(request.GET.items())
if not any(param.startswith('is_published') for param in query_params.keys()):
    query_params['is_published'] = True
if not any(param.startswith('id') for param in query_params.keys()):
    query_params['id__lt'] = 10
q_filter = Q(**query_params)
posts = Post.objects.filter(q_filter)

Several mistakes are visible here:

• The code takes the user's GET parameters without validation.
• It inserts them directly into a Q object.
• It attempts to enforce constraints like is_published=True, but those conditions can be neutralized by overriding _connector.

Now that we understand how the bug works at a technical level, let's see how it can be exploited in practice inside the TryHackMe environment

4.1 Retrieving All Blog Posts

The posts page is available at:

http://TARGET/poc/

By default, you only see a few posts because the view forces:

• is_published=True
• id < 10

To bypass these filters, we inject a malicious connector:

http://TARGET/poc/?author=Security%20Architect&_connector=OR%201=1%20OR

Here is what happens:

1. Django builds a Q object with author="Security Architect" and _connector="OR 1=1 OR".
2. Instead of applying strict AND logic, the query is rewritten into a condition that always evaluates to true.
3. All posts in the database, including unpublished ones, become visible.

We can now scroll or search through the list and find the post written by the DevOps Engineer:

Answer : Monitoring Django Apps — Advanced

4.2 Retrieving All Employees

The Employee page performs this query:

employees = Employee.objects.filter(is_active=True).order_by('last_name')

At:

http://TARGET/poc/employees

To override the is_active=True filter, we again inject a malicious connector:

http://TARGET/poc/employees/?hire_date__year=2022&_connector=OR%201=1%20OR

This forces the logic into an always true condition, revealing all employees, including inactive ones.

Searching for the employee with hire date June 5, 2022 gives:

Answer : David Rodriguez

This confirms that the application no longer respects internal access controls because the filter logic has been overridden.

5. Conclusion

In real production environments, this vulnerability could expose private user data, internal admin-only records, draft content, financial information, and other sensitive datasets. Any application that dynamically builds ORM queries based on user parameters is at high risk if proper sanitization is not enforced.

The TryHackMe room provides a practical demonstration of this issue. By injecting a malicious connector, we were able to:

• Reveal unpublished blog posts
• Reveal inactive employees
• Retrieve data beyond the intended access restrictions

Django has patched the issue by rejecting internal parameters in QuerySet constructors. However, the real lesson is that safe frameworks do not guarantee safe applications. Developers must always validate and sanitize user input before passing it into any query building function.