Django 6.1.3の脆弱性6件 Varyのキャッシュを手元で再現

Djangoで作った業務システムの保守では、セキュリティリリースのたびに「この修正はうちに関係あるのか」を判断する必要があります。全部が自社に当てはまるわけではありませんが、当てはまらないと言い切るには、どの機能を使っていれば影響を受けるのかを知っておかなければなりません。

2026年11月3日に公開されたDjango 6.1.3では、6件の脆弱性が修正されました。本記事では、Djangoの公式の告知とリリースノートの原文から、6件それぞれが「どの機能を使っていると関係するか」を整理し、そのうちキャッシュの1件を手元で再現した結果を示します。

公開された版と、修正の件数

同じ日に、3つの系列で修正版が出ています（PyPIの公開時刻はいずれも11月3日 15:21〜15:22 UTC）。

• 6.1.3：「low」5件、「moderate」1件。あわせて6.1.2の不具合の修正と、Python 3.15への対応
• 6.0.10：「low」5件、「moderate」1件
• 5.2.19：「low」4件、「moderate」1件（管理画面のパスワードのハッシュの件は含まれない）

深刻度は、Djangoのセキュリティポリシーの基準によるものです。ポリシーでは、遠隔でのコード実行とSQLインジェクションを「High」、XSS・CSRF・認証の不備を「Moderate」、サービス妨害・機密データの露出・まれな設定が必要な問題などを「Low」としています。今回は「High」はありません。6.1系列の次の版（6.1.4）は、12月1日の予定と書かれています。

公式の告知は、影響を受けるサポート中の系列を main・6.1・6.0・5.2 としています。ダウンロードページでは、セキュリティの修正が出る系列は 6.1・6.0・5.2 LTS の3つで、4.2 LTS は2026年4月7日にサポートを終えています。4.2以前を使っているシステムには修正版が出ないため、サポート中の系列への移行を先に検討する必要があります。

6件は、どの機能を使っていると関係するか

下の3件は、GeoDjango（django.contrib.gis）を使っていなければ関係しません。上の3件は、ファイルのアップロード、キャッシュ、管理画面に関わります。業務システムで使っているかを先に確かめたい機能です。

GeoDjangoを使っている場合は、版を上げるだけでは終わらない点があります。SpatialReference の修正は、GDAL 3.9以降でネットワークとファイルへのアクセスを止める形で、原文は「Full protection requires GDAL 3.9 or later」としています。この修正により、ファイルのパスやURLは SpatialReference の入力として受け付けなくなり、DICT: で始まる参照はGDALの版に関係なく拒否されます。これらを入力に使っている処理は、更新後に動かなくなる点に注意が要ります。新しいシステムチェック gis.W001 が、GDALが3.9より古いと警告します。信頼できない入力には整数のSRIDを使う、文字列なら許可する値と照合する、という勧めも書かれています。なお、GeoJSONの読み込みに使う DataSource と LayerMapping は、信頼できるデータの読み込み用として、引き続き外部の参照を受け付けます。

Varyのキャッシュの件を、手元で再現した

キャッシュの件は、会員向けと一般向けで内容が変わるページを、ヘッダーで出し分けてキャッシュしている場合に関係します。6.1.2と6.1.3の両方で同じスクリプトを実行しました。11月10日にLinuxの検証環境で、11月11日に編集部のPC（macOS）で各1回実行し、どちらも同じ結果でした（Python 3.13、メモリ上のキャッシュ、RequestFactory による要求。ヘッダー名と値は架空のもの）。

ビューは cache_page を付け、応答に Vary: X-Tenant を付けます。X-Tenant を送らない要求には「public page」、送った要求には「tenant view: 値」を返します。まず X-Tenant を空で送り、次に送らずに要求しました。

6.1.2では、ヘッダーを送らなかった要求に、空で送った要求のためのキャッシュが返りました。6.1.3では2つが区別され、それぞれのビューが動いています。スクリプトと出力は本記事の制作記録に残しています。

現実のシステムでは、認証の情報を独自のヘッダーで受け取り、Vary に挙げてキャッシュしている場合に、この違いが問題になりえます。原文には、更新後は、ヘッダーを送らなかった要求の既存のキャッシュが一致しなくなり、次の要求で作り直されるとも書かれています。更新の直後に、キャッシュの作り直しの分だけ負荷が上がる可能性を見込んでおきます。

更新の進め方（編集部の提案）

ここからは編集部の提案です。

1. 使っている系列を確かめる。python -m django --version で、6.1・6.0・5.2のどれかを見ます
2. 上の表で、関係する機能を使っているかを洗い出す。MultiPartParser は通常のファイルのアップロードの受け付けで使われます。キャッシュは settings.py の MIDDLEWARE と、cache_page の使い方を探します
3. GeoDjangoを使っていれば、GDALの版も確かめる。版を上げたあとに python manage.py check を実行し、gis.W001 が出ないかを見ます
4. 6.1.3・6.0.10・5.2.19に上げ、検証環境でテストを通してから本番に出す

依存のパッケージの更新を、公開直後に取り込みすぎない仕組みについては、pipの依存のクールダウンの記事で扱いました。セキュリティリリースのように急いで取り込みたい更新との使い分けも、あわせて決めておくと判断が早くなります。フレームワークの更新だけでは見つからない作り込みの問題は、脆弱性診断の記事で扱った診断で確かめます。

確認した範囲

2026年11月10日に、django/djangoの docs/releases/6.1.3.txt・6.0.10.txt・5.2.19.txt・6.1.4.txt、docs/internals/security.txt の深刻度の基準、stable/6.1.xブランチのコミット（修正と版上げ）、PyPIの公開時刻を確認しました（資料調査）。キャッシュの件は、Django 6.1.2と6.1.3をそれぞれインストールし、同じスクリプトを実行しました（実機検証。11月10日にLinuxの検証環境で、11月11日に編集部のPC〔macOS、Python 3.13.16〕で各1回）。2026年11月11日に、djangoproject.comのセキュリティの告知（11月3日）とダウンロードページのサポート中の系列を確かめ、6.1.3より新しい版が出ていないこともPyPIで確認しました。GeoDjangoの3件、アップロードの件、管理画面の件は再現していません。

Djangoで作った業務システムの保守や、セキュリティリリースへの対応の段取りづくりは、グリームハブの開発・AI・自動化のご相談で承っています。システムの構成によって確かめる点が変わるため、お問い合わせからご相談ください。

参考資料

• Django security releases issued: 6.1.3, 6.0.10, and 5.2.19（Django Weblog、2026-11-03）
• Django — Download（Supported Versions）
• django/django — docs/releases/6.1.3.txt
• django/django — docs/releases/6.0.10.txt
• django/django — docs/releases/5.2.19.txt
• django/django — docs/internals/security.txt（Security severity levels）
• Django — PyPI