Django закрыл 6 уязвимостей безопасности. Среди них SSRF, утечка паролей и раскрытие пользовательских данных

3 ноября команда Django выпустила экстренные обновления безопасности для трёх веток фреймворка:

- Django 6.1.3
- Django 6.0.10
- Django 5.2.19

Всего исправлено 6 уязвимостей: одна средней и пять низкой степени серьёзности.

Что обнаружили:

1. SSRF через GeoJSON

Злоумышленник мог передать вредоносный URL в поле crs геометрии GeoJSON. GDAL обращался к внешнему ресурсу или читал локальные файлы от имени Django-процесса.

2. SSRF через SpatialReference

Строковые значения, переданные в SpatialReference и связанные GIS-методы, могли заставить GDAL обращаться к URL или читать файлы на сервере.

3. Утечка приватных данных через кеш

UpdateCacheMiddleware и cache_page() могли создавать одинаковые ключи кеша для запросов с отсутствующим и пустым HTTP-заголовком из Vary. В результате один пользователь мог получить закешированный ответ другого.

4. Раскрытие хешей паролей

В Django Admin пользователи с правом только на просмотр могли видеть полные хеши паролей при определённых конфигурациях пользовательских моделей.

5. Исчерпание памяти при загрузке файлов

MultiPartParser мог полностью буферизовать multipart-файлы с Content-Transfer-Encoding: base64, игнорируя ограничение FILE_UPLOAD_MAX_MEMORY_SIZE.

6. Log Injection

Некорректные значения геометрических полей записывались в логи без экранирования управляющих символов. Это позволяло подделывать записи и изменять отображение логов.

Что делать разработчикам?

Обновить Django до исправленной версии своей ветки. Для GIS-приложений также проверить версию GDAL: полноценная защита от проблемы с SpatialReference требует GDAL 3.9 или новее.

Особенно внимательно стоит проверить приложения, принимающие пользовательский GeoJSON, работающие с GIS-данными и использующие кеширование персонализированных ответов.

Исходный отчёт: https://www.djangoproject.com/weblog/2026/nov/03/security-releases/

Одна правка документа перегрузила PostgreSQL. Как в Django переделали кеш

Команда Джонни Метца хранила в Redis готовый список документов для каждого пользователя. Когда крупный клиент изменил одну общую запись, обработчик сбросил кеш тысяч пользователей. Их следующие запросы почти одновременно пошли в PostgreSQL, и API несколько минут работал медленнее.

Кеш разделили. Для пользователя хранят только ID доступных ему документов. Каждый документ лежит в Redis в одном экземпляре, а Django забирает нужные записи пачкой через get_many. Поле can_edit вычисляют при сборке ответа с учётом прав конкретного пользователя. Теперь при переименовании документа достаточно удалить один ключ doc:<id>.

TTL увеличили до семи дней. Ключи удаляют после коммита через transaction.on_commit: если удалить ключ раньше, параллельный запрос может снова положить в кеш старые данные. При промахе читают из primary, чтобы в кеш не попала устаревшая версия с отстающей реплики.

За три месяца внедрения трафик вырос примерно на 40%, средняя задержка упала примерно на 40%, а число запросов к БД в секунду сократилось вдвое. На обычном пике API обслуживает около 1 100 запросов в секунду, доля попаданий в кеш составляет 97%.

https://johnnymetz.com/posts/caching-at-scale-in-django/