В Django 6.1.3, опубликованном 3 ноября 2026 года, исправили шесть уязвимостей: от возможной утечки данных через кеш до серверных запросов по адресам, переданным в географических данных. Релиз также устраняет ошибку ORM, из-за которой терялись изменения объектов в памяти, и добавляет совместимость с Python 3.15.
Кеш Django больше не смешивает отсутствующие и пустые HTTP-заголовки
Одна из исправленных проблем, CVE-2026-113593, затрагивала механизм кеширования страниц. В Django ответ может содержать заголовок Vary: он сообщает, какие заголовки запроса влияют на содержимое страницы. Например, сервер может формировать разные ответы в зависимости от языка посетителя или другого признака, переданного в HTTP-запросе.
До исправления UpdateCacheMiddleware и декоратор cache_page() одинаково вычисляли ключ кеша в двух разных ситуациях: когда определённого заголовка в запросе вообще нет и когда он присутствует с пустым значением. Из-за совпадения ключей ответ, сохранённый для одного запроса, мог попасть в другой. Команда Django прямо указывает на потенциальное раскрытие приватных данных при таком совпадении.
В версии 6.1.3 отсутствие заголовка и его пустое значение учитываются раздельно. Это соответствует правилам HTTP-кеширования из RFC 9111. Есть и непосредственное последствие для работающих сайтов: старые записи кеша, созданные для запросов с отсутствующим заголовком из Vary, перестанут совпадать с новыми ключами и будут созданы заново при следующих запросах. Уязвимость получила низкую оценку серьёзности по классификации Django.
GeoDjango перекрыл опасные обращения к внешним адресам
Самая серьёзная из шести уязвимостей — CVE-2026-111362, оценённая разработчиками Django как умеренная. Она относится к GeoDjango — компоненту для работы с географическими координатами, геометрическими объектами и пространственными запросами.
Причина связана со старыми вариантами формата GeoJSON. В них допускалось указывать систему координат (CRS) через URL. Библиотека GDAL, которую использует GeoDjango, могла обращаться по такому адресу при разборе геометрии. Если приложение принимало географические данные от постороннего пользователя, специально подготовленный объект мог заставить сервер отправить сетевой запрос или прочитать локальный файл. Этот класс проблем называется SSRF — подделка запросов от имени сервера.
Django 6.1.3 отклоняет внешние ссылки на CRS при обработке GeoJSON через GEOSGeometry, географические поля форм и пространственные фильтры. При этом служебные инструменты DataSource и LayerMapping, предназначенные для загрузки доверенных данных, сохраняют прежнее поведение. Поэтому речь идёт о защите конкретных путей обработки пользовательского ввода, а не о запрете всех внешних источников геоданных.
Вторая проблема того же семейства, CVE-2026-114582, затрагивала SpatialReference и методы преобразования геометрии и растров. Строковое значение могло передаваться в GDAL, которая при определённых условиях обращалась к сети или локальным файлам. В исправленной версии такое обращение блокируется при использовании GDAL 3.9 или новее. Для более старых сборок полной защиты этого пути нет: Django добавил системное предупреждение gis.W001, указывающее на версию GDAL ниже 3.9. Целочисленные идентификаторы систем координат (SRID) обрабатываются через базу EPSG без обращения к внешним адресам.
Загрузка файлов и административная панель получили дополнительные исправления
Ещё три изменения касаются разных способов обработки пользовательского ввода.
CVE-2026-108147 связана с загрузкой файлов. Если multipart-запрос содержал файл в кодировке base64 и заголовок Content-Transfer-Encoding: base64, MultiPartParser мог целиком поместить его в оперативную память ещё до передачи обработчикам загрузки. Ограничение FILE_UPLOAD_MAX_MEMORY_SIZE при этом не предотвращало такое буферизование. Возможным последствием было чрезмерное потребление памяти сервером.
CVE-2026-111211 затрагивала сообщения об ошибках в географических формах GeometryField. Недопустимые значения записывались в журналы без экранирования управляющих символов. Злоумышленник мог влиять на внешний вид или структуру записей, например подставляя переносы строк или ANSI-последовательности. Такое вмешательство затрудняет анализ логов и способно вводить в заблуждение системы их обработки.
CVE-2026-113733 относилась к административному интерфейсу с нестандартными моделями пользователей. При определённых конфигурациях сотрудник, имевший право только просматривать запись пользователя, видел полный хеш пароля. Проблема проявлялась, если просматриваемая модель отличалась от AUTH_USER_MODEL либо поле password наследовалось через многоуровневое наследование моделей. Это раскрытие хеша, а не пароля в открытом виде; доступ к значению всё равно нарушал предполагаемое разграничение прав.
Все три уязвимости получили низкий уровень серьёзности по политике безопасности Django.
Исправление FETCH_PEERS защищает изменения объектов в ORM
Помимо безопасности, Django 6.1.3 исправляет ошибку режима FETCH_PEERS, появившегося в ветке 6.1. Этот режим позволяет ORM подгружать отложенные поля сразу для нескольких связанных экземпляров, сокращая число отдельных обращений к базе.
В предыдущем поведении возникала неприятная ситуация. Приложение получало несколько объектов с отложенным полем, изменяло значение этого поля у одного объекта в памяти, а затем обращалось к тому же полю у другого. Групповая догрузка могла повторно записать значение из базы в первый объект и затереть ещё не сохранённое локальное изменение. Похожая ошибка возникала после явного refresh_from_db(fields=...). Если одну из записей успевали удалить из базы, чтение поля у соседнего объекта могло завершиться исключением KeyError.
Исправление по задаче #37436 сохраняет уже загруженные или вручную изменённые значения и корректно обрабатывает отсутствие удалённых записей. Разница особенно ощутима в коде, где объекты сначала собираются в список, а затем их поля изменяются до сохранения.
В том же релизе исправлены сбои сериализации YAML с параметром sort_keys, отдельный случай фильтрации JSONField в SQLite и повторное добавление CSS-класса обязательного поля через legend_tag().
Python 3.15 и Windows — расширенная совместимость Django 6.1
Версия 6.1.3 официально добавляет поддержку Python 3.15. В результате ветка Django 6.1 поддерживает Python 3.12, 3.13, 3.14 и 3.15. Это даёт проектам на Django 6.1 возможность использовать новую ветку интерпретатора в рамках заявленной совместимости самого фреймворка.
С обновлением связан и конкретный исправленный сбой: на Windows команда makemessages, которая извлекает строки интерфейса для перевода, могла завершаться ошибкой при обработке файлов с символами вне ASCII. Проблема проявлялась на Python 3.15 и новее, а также в более ранних версиях Python с включённым режимом UTF-8. Дополнительно обеспечена совместимость с драйвером базы данных oracledb 26.0.0 и более поздними версиями.
Какие версии Django получили исправления безопасности
Проблемы безопасности затронули поддерживаемые ветки Django 6.1, 6.0 и 5.2. Поэтому 3 ноября одновременно были выпущены три обновления: 6.1.3, 6.0.10 и 5.2.19. Разработчики рекомендуют устанавливать исправленные версии в соответствующих ветках.
Для проекта, уже работающего на Django 6.1, обновление через pip можно ограничить конкретным выпуском:
python -m pip install --upgrade "Django==6.1.3"Установленную версию можно проверить командой python -m django --version. После смены версии официальное руководство Django предусматривает запуск тестов приложения; для проектов с GeoDjango отдельное значение имеет диагностика версии GDAL и предупреждение gis.W001.
Что меняет ноябрьский выпуск для существующих сайтов
Исправление Vary затрагивает сайты с кешированием ответов по HTTP-заголовкам. Ограничения GeoDjango относятся к приложениям, которые принимают или преобразуют географические данные, причём защита одного из путей зависит от установленной GDAL. Поправка FETCH_PEERS устраняет потерю локальных значений при групповой догрузке полей ORM.
Таким образом, последствия обновления определяются конфигурацией конкретного Django-проекта: используемыми механизмами кеша, географическими библиотеками, моделями административной панели и режимом загрузки полей из базы.
