4 августа 2026 года разработчики Django выпустили обновления версий 6.0.8 и 5.2.17, в которых устранили четыре критические уязвимости. Наиболее серьёзная проблема заключалась в работе пространственных фильтров GeoDjango: злоумышленник с правами на просмотр мог передать значение, которое GDAL интерпретировал как растровое изображение, и затем записать файл на сервер или отправить сетевой запрос от имени процесса Django.
Фильтр в админ-панели открывал доступ к опасным возможностям GDAL
История с CVE-2026-15307 выглядит неожиданно из-за точки входа. Уязвимость находилась в пространственных lookup-запросах GeoDjango — механизме, который фильтрует объекты по координатам, полигонам и растровым данным. В административной панели такой фильтр мог быть доступен сотруднику, у которого было лишь право просмотра модели с пространственным полем.
До исправления lookup принимал значения типов str и dict, если они описывали растр. Django передавал их в GDALRaster, а дальнейшее поведение зависело от драйвера GDAL. Некоторые драйверы умеют работать с файлами и сетевыми источниками. Специально составленное значение могло привести к записи файла на диск или к исходящему запросу от имени серверного процесса. В отдельных конфигурациях запись файла создавала условия для удалённого выполнения кода.
Здесь есть существенное ограничение: официальный бюллетень описывает доступ через учётную запись сотрудника с разрешением на просмотр зарегистрированной в админке модели, содержащей пространственное поле. Публичная форма сайта сама по себе такой путь не открывала. Риск возрастал в системах, где административные права распределены между операторами, редакторами, диспетчерами или аналитиками, а GeoDjango используется для карт, зон доставки, кадастровых объектов и других GIS-данных.
Команда Django присвоила CVE-2026-15307 высокий уровень опасности. Подробности опубликованы в официальном бюллетене безопасности Django.
Четыре CVE затронули GIS, локализацию и административный интерфейс
Выпуск закрывает одну уязвимость высокой опасности, две умеренной и одну низкой. Три проблемы затрагивают обработку входных данных, ещё одна связана с тем, как административная панель превращала сохранённый адрес в кликабельную ссылку.
| Уязвимость | Уровень | Компонент | Механизм | Изменение в исправленных версиях |
| CVE-2026-15307 | Высокий | GeoDjango, GDALRaster, spatial lookups | Строка или словарь могли инициировать запись файла либо сетевой запрос через драйвер GDAL | Lookup больше не принимает dict и строки, которые нельзя разобрать как корректный GEOSGeometry |
| CVE-2026-15337 | Низкий | check_for_language() | Множество уникальных длинных кодов языка заполняло кэш и расходовало память процесса | Коды языка длиннее 500 символов отклоняются до обращения к кэшу |
| CVE-2026-15830 | Умеренный | GEOSGeometry, GeometryField | Глубоко вложенные GEOMETRYCOLLECTION могли вызвать segmentation fault в GEOS | Для WKT и WKB введён предел 198 коллекций; появился параметр max_geom_collections |
| CVE-2026-15920 | Умеренный | URLField в Django Admin | Опасная схема URL сохранялась в поле и показывалась как кликабельная ссылка | Значение проходит через URLValidator; некорректный адрес отображается обычным текстом |
Все четыре исправления вошли в ветки Django 6.0 и Django 5.2 LTS. Патчи применены и к основной ветке разработки, и к Django 6.1, который на момент публикации бюллетеня находился в статусе release candidate.
GeoDjango ограничил типы значений и глубину геометрических коллекций
Два из четырёх исправлений сосредоточены вокруг географических данных. GeoDjango связывает модели Django с пространственными типами баз данных и библиотеками GEOS и GDAL. Такой стек используют сервисы доставки, геопорталы, системы мониторинга транспорта, приложения с геозонами и административные карты.
После CVE-2026-15307 пространственные lookup-запросы больше не принимают словари. Строка допускается только тогда, когда её можно разобрать как корректный объект GEOSGeometry. Это изменение нарушает обратную совместимость для проектов, которые передавали сериализованные словари или другие строковые описания растров прямо в фильтры ORM.
Назначение значений полям модели сохранило прежнее поведение. Ограничение относится именно к lookup-запросам, где входные данные участвуют в построении условия выборки. В документации GDAL API команда отдельно описывает риски растровых источников и способы явной проверки данных перед созданием объекта.
Вторая GIS-уязвимость, CVE-2026-15830, работала через вложенные GEOMETRYCOLLECTION. Этот формат позволяет объединять несколько геометрий в одну структуру. Очень глубокая вложенность приводила к аварийному завершению библиотеки GEOS, а вместе с ней мог падать рабочий процесс веб-приложения.
Исправленные версии ограничивают глубину WKT-структуры 198 коллекциями. Для WKB действует общий предел 198 коллекций с учётом ширины и глубины дерева. Значение можно менять через новый аргумент max_geom_collections, доступный в GEOSGeometry, поле формы и поле модели. Входные данные GeoJSON этим ограничением не затронуты, поскольку их разбирает GDAL и описанная ошибка в этом пути не проявлялась.
Длинные коды языка больше не раздувают кэш процесса
CVE-2026-15337 затронула функцию django.utils.translation.check_for_language(). Она проверяет, существует ли указанный языковой код, и сохраняет результат в памяти, чтобы последующие обращения выполнялись быстрее.
Проблема возникала при обработке большого количества разных и очень длинных значений. Каждое из них становилось отдельным ключом кэша, поэтому атакующий мог постепенно увеличивать расход памяти. Значение поступало через представление django.views.i18n.set_language() из POST-запроса.
Масштаб атаки был ограничен двумя механизмами. Представление set_language() подключается только явно. Объём тела запроса контролируется настройкой DATA_UPLOAD_MAX_MEMORY_SIZE, а сам кэш имеет предел количества записей. По этой причине команда Django оценила уязвимость как низкую.
В Django 6.0.8 и 5.2.17 языковой код длиной более 500 символов отбрасывается до кэшируемой проверки. Обычные коды вроде ru, en-us или pt-br находятся далеко от этого порога, поэтому поведение стандартного переключателя языка остаётся прежним.
URLField в Django Admin проходит проверку перед созданием ссылки
CVE-2026-15920 связана с сохранённым XSS — сценарием, при котором опасное значение сначала попадает в базу данных, а затем срабатывает при просмотре страницы другим пользователем.
Django Admin показывает значения URLField как кликабельные ссылки в списках объектов и полях только для чтения. Раньше функция отображения создавала ссылку без проверки безопасной схемы адреса. Записанное значение с потенциально опасной схемой сохраняло кликабельный вид в административном интерфейсе.
После исправления display_for_field передаёт адрес в URLValidator. Валидный URL отображается ссылкой, а значение, которое проверку не прошло, выводится обычным текстом. Механизм сохраняет видимость данных для администратора и убирает браузерный переход по опасной схеме.
Эта ошибка получила умеренный уровень опасности. Для эксплуатации атакующему требовалась возможность записать подготовленное значение в URLField, после чего сотрудник должен был открыть соответствующий список или карточку в Django Admin.
Django 5.2 LTS и 6.0 получили одинаковый набор исправлений
Официальная страница загрузки теперь указывает Django 5.2.17 как актуальный выпуск LTS-ветки, а Django 6.0.8 — как актуальный выпуск серии 6.0. Поддержка безопасности Django 5.2 LTS заявлена до апреля 2028 года, серии 6.0 — до апреля 2027 года.
Такое параллельное исправление имеет практическое значение для инфраструктуры. Проекты на LTS-ветке получают те же четыре патча без перехода на новую функциональную серию. Проекты на 6.0 сохраняют текущую ветку и закрывают уязвимости обновлением патч-версии.
Django 4.2 LTS в список выпусков от 4 августа не вошёл. Его расширенная поддержка завершилась в апреле 2026 года, поэтому новые исправления для этой серии больше не публикуются. В бюллетене среди затронутых поддерживаемых веток перечислены main, Django 6.1 RC, Django 6.0 и Django 5.2.
Примечания к выпуску Django 5.2.17 повторяют классификацию: одна уязвимость высокой опасности, две умеренной и одна низкой. Для Django 6.0.8 выпущен тот же набор исправлений.
Исправления закрыли известные пути атаки, а GeoDjango получил несовместимое изменение
На 5 августа 2026 года четыре описанные уязвимости закрыты в поддерживаемых ветках Django 5.2 и 6.0, а также в коде будущей серии 6.1. Самый широкий по последствиям сценарий требовал GeoDjango, пространственного поля в административной панели и учётной записи сотрудника с правом просмотра. Остальные проблемы зависели от конкретных функций: переключения языка, обработки сложной геометрии или вывода URLField в Django Admin.
Запрет словарей и части строковых значений в spatial lookups меняет прежнее поведение ORM. Проекты, использовавшие такие значения напрямую, могут столкнуться с ошибками в существующих запросах после установки патча. Масштаб этой несовместимости пока неизвестен: официальный бюллетень фиксирует новый контракт типов, но не приводит данных о распространённости старого способа.
Неясно, применялись ли уязвимости на практике до того, как были выпущены исправления. Команда Django перечислила исследователей, которые обнаружили ошибки, но в бюллетене нет информации о реальных атаках.
