HashiCorp, Veeam и Django Software Foundation закрыли 11 уязвимостей: три в Terraform MCP Server, четыре в Veeam Service Provider Console и четыре в Django. Самая высокая оценка, CVSS 10.0, присвоена ошибке межклиентского повторного использования токенов Terraform. У Veeam максимум составил 9.5, а в Django наиболее опасная проблема затронула GeoDjango и при определённых условиях допускала удалённое выполнение кода. Требуемые версии: Terraform MCP Server 1.1.0 или новее, VSPC 9.3.0.35057, Django 6.0.8 либо 5.2.17. По состоянию на 5 августа 2026 года разработчики не сообщали об активной эксплуатации новых ошибок, публичных прототипов эксплойтов не было, ни одна из 11 CVE не находилась в каталоге известных эксплуатируемых уязвимостей CISA KEV.
Veeam Service Provider Console используют хостинговые компании и поставщики управляемых услуг для контроля резервных копий разных клиентов из одной консоли. Исправленная сборка 9.3.0.35057 вышла 29 июля 2026 года, бюллетень безопасности появился 4 августа. Уязвимы VSPC 9.2.1.33875 и все более ранние сборки девятой версии. Из четырёх найденных ошибок две получили критический статус, ещё две — высокий. Для такой многопользовательской системы особенно неприятны проблемы, позволяющие выдать себя за управляемый агент или на короткое время добраться до привилегированного API.
CVE-2026-58073 с оценкой CVSS 9.5 позволяет атакующему без учётной записи имитировать управляемый агент и получить его реквизиты доступа. Сложность атаки обозначена как высокая, поэтому отсутствие обязательной аутентификации не делает эксплуатацию простой. CVE-2026-58072, CVSS 9.0, требует лишь низкопривилегированной учётной записи: через неё можно записать произвольный файл на сервер управления и затем добиться удалённого выполнения кода. CVE-2026-58067 не требует входа и вызывает отказ в обслуживании за счёт исчерпания памяти. CVE-2026-58071 открывает проксированный API устройства с правами Portal Administrator в течение короткого промежутка после начала администраторского сеанса.
Для Veeam это второй цикл критических исправлений примерно за три месяца. В мае 2026 года компания закрыла CVE-2026-32998 с оценкой CVSS 9.4: уязвимость удалённого выполнения кода была связана с запуском сценариев тревожных уведомлений. Повторное появление критических ошибок именно в VSPC повышает цену задержки обновления: консоль управляет инфраструктурой клиентов, а не одним изолированным сервером. Проверять нужно все установки версии 9, начиная со сборки 9.2.1.33875 и ниже, даже если сама консоль недоступна напрямую из интернета.
HashiCorp Terraform MCP Server соединяет ИИ-ассистентов с Terraform через Model Context Protocol. Три уязвимости раскрыли 28 июля 2026 года и исправили в версии 1.1.0. В опубликованных материалах встречается фраза «2.0 от 4 августа», но первым исправленным выпуском во всех согласующихся данных указана именно 1.1.0. Есть и другая нестыковка: общий бюллетень считает затронутыми версии с 0.2.1 по 1.0.0, отдельные записи CVE начинают диапазон с 0.3.0. Обе версии описания сходятся в одном: переход на 1.1.0 или новее закрывает ошибки. Оценки CVSS взяты из записей CVE, поскольку сам бюллетень HashiCorp баллы не приводил.
Все три проблемы относятся к транспорту Streamable HTTP. Локальный однопользовательский режим stdio не затронут. Централизованную HTTP-конфигурацию для нескольких пользователей HashiCorp продвигала после выхода сервера в общую доступность в июне 2026 года. В намеренно включаемом stateless-режиме CVE-2026-16498, CVSS 10.0, возникала из-за того, что базовая MCP-библиотека не назначала уникальные идентификаторы сеансов, хотя кэш реквизитов Terraform полагался на них при разделении клиентов. В итоге токен одного пользователя мог применяться к последующим запросам других пользователей вне зависимости от переданных ими токенов. Корень ошибки довольно прозаичен: сервер ожидал от нижележащего MCP-слоя гарантии, которой в stateless-режиме не существовало.
CVE-2026-16496, CVSS 8.9, затрагивает stateful-режим, используемый по умолчанию в централизованных установках. Кэш искал Terraform-клиент только по идентификатору MCP-сеанса и не связывал его с токеном, создавшим этот клиент. Получив чужой идентификатор сеанса, атакующий мог вызывать инструменты через Terraform-клиент жертвы и обращаться к ресурсам в пределах прав её токена. Эту ошибку сообщил Juan Pablo Martinez Kuhn из Coinspect, две остальные HashiCorp нашла сама. CVE-2026-14869, CVSS 8.6, представляет собой SSRF: промежуточное ПО отклоняло переданный клиентом адрес Terraform в HTTP-заголовке, но пропускало то же значение в параметре запроса. Любой, кто мог достучаться до Streamable HTTP listener, получал возможность заставить сервер отправить настроенный bearer-токен на подконтрольный адрес, причём вход в систему не требовался.
Сравнивать оценки Veeam и HashiCorp напрямую нельзя: Veeam применяла CVSS 4.0, записи HashiCorp рассчитаны по CVSS 3.1. Практическая доступность тоже не совпадает с порядком баллов. CVE-2026-16498 с максимальными 10.0 работает лишь в stateless-режиме, который оператор включает вручную; CVE-2026-16496 с оценкой 8.9 затрагивает стандартный stateful-вариант централизованного сервера. Если немедленный переход на Terraform MCP Server 1.1.0 невозможен, доступ к Streamable HTTP listener следует оставить только доверенным пользователям, а идентификаторы MCP-сеансов хранить как секретные значения.
Django Software Foundation выпустила Django 6.0.8 и 5.2.17 4 августа 2026 года, перенесла исправления в основную ветку разработки и ветку релиз-кандидата Django 6.1. Единственная уязвимость высокой степени опасности, CVE-2026-15307, находится в GeoDjango. Пространственные запросы принимали значения str и dict, похожие на растры, и передавали их в GDALRaster. В зависимости от растрового драйвера это позволяло записать файл на диск либо инициировать сетевой запрос. Если файл попадал в каталог, откуда приложение позднее импортировало код, результатом могло стать удалённое выполнение кода. Описанный разработчиками путь через административную панель требует учётной записи сотрудника с правом просмотра зарегистрированной модели, содержащей пространственное поле. Исправление запрещает dict и строки, не являющиеся корректными значениями GEOSGeometry, в пространственных запросах; изменение нарушает обратную совместимость, хотя прямое присваивание полям модели по-прежнему принимает такие типы.
Оставшиеся ошибки Django получили умеренные и низкую оценки. CVE-2026-15920 — хранимая межсайтовая подстановка сценариев: небезопасное значение URLField отображалось в административной панели как ссылка, а код выполнялся после щелчка. CVE-2026-15830 позволяла вызвать отказ в обслуживании через глубоко вложенные объекты GEOMETRYCOLLECTION, доводившие GEOS до ошибки сегментации; теперь глубина ограничена 198 коллекциями. CVE-2026-15337 расходовала память через функцию check_for_language(), поэтому исправленная версия отбрасывает языковые коды длиннее 500 символов. Неподдерживаемые Django 5.1, 5.0 и 4.2 не проверялись и тоже могут содержать эти ошибки. При обновлении стоит отдельно пересмотреть права сотрудников, модели с пространственными полями, использование растров GeoDjango, значения URLField, вложенные геометрические коллекции и обработку языковых кодов.
Интерес атакующих к географическому коду Django уже подтверждён событиями 2026 года. В феврале была исправлена CVE-2026-1207 — SQL-инъекция в растровых запросах PostGIS. CrowdSec выпустила правило обнаружения 18 февраля, а первые атаки заметила 26 февраля; позднее продолжалось устойчивое сканирование сайтов в поисках установок Django с PostGIS. Для эксплуатации требовались backend PostGIS и пользовательский ввод, попадающий в конкретный запрос. Само зондирование могло определить тип приложения, но не взламывало его. Для новой CVE-2026-15307 этого также недостаточно: описанный маршрут требует учётной записи сотрудника с подходящим правом просмотра. Тем не менее проверки GIS- и raster-кода уже ведутся в реальной сети, поэтому отсутствие CVE-2026-15307, CVE-2026-15920, CVE-2026-15830 и CVE-2026-15337 в CISA KEV на 5 августа 2026 года не отменяет обновление до Django 6.0.8 или 5.2.17.[/final]
Изображение носит иллюстративный характер
Veeam Service Provider Console используют хостинговые компании и поставщики управляемых услуг для контроля резервных копий разных клиентов из одной консоли. Исправленная сборка 9.3.0.35057 вышла 29 июля 2026 года, бюллетень безопасности появился 4 августа. Уязвимы VSPC 9.2.1.33875 и все более ранние сборки девятой версии. Из четырёх найденных ошибок две получили критический статус, ещё две — высокий. Для такой многопользовательской системы особенно неприятны проблемы, позволяющие выдать себя за управляемый агент или на короткое время добраться до привилегированного API.
CVE-2026-58073 с оценкой CVSS 9.5 позволяет атакующему без учётной записи имитировать управляемый агент и получить его реквизиты доступа. Сложность атаки обозначена как высокая, поэтому отсутствие обязательной аутентификации не делает эксплуатацию простой. CVE-2026-58072, CVSS 9.0, требует лишь низкопривилегированной учётной записи: через неё можно записать произвольный файл на сервер управления и затем добиться удалённого выполнения кода. CVE-2026-58067 не требует входа и вызывает отказ в обслуживании за счёт исчерпания памяти. CVE-2026-58071 открывает проксированный API устройства с правами Portal Administrator в течение короткого промежутка после начала администраторского сеанса.
Для Veeam это второй цикл критических исправлений примерно за три месяца. В мае 2026 года компания закрыла CVE-2026-32998 с оценкой CVSS 9.4: уязвимость удалённого выполнения кода была связана с запуском сценариев тревожных уведомлений. Повторное появление критических ошибок именно в VSPC повышает цену задержки обновления: консоль управляет инфраструктурой клиентов, а не одним изолированным сервером. Проверять нужно все установки версии 9, начиная со сборки 9.2.1.33875 и ниже, даже если сама консоль недоступна напрямую из интернета.
HashiCorp Terraform MCP Server соединяет ИИ-ассистентов с Terraform через Model Context Protocol. Три уязвимости раскрыли 28 июля 2026 года и исправили в версии 1.1.0. В опубликованных материалах встречается фраза «2.0 от 4 августа», но первым исправленным выпуском во всех согласующихся данных указана именно 1.1.0. Есть и другая нестыковка: общий бюллетень считает затронутыми версии с 0.2.1 по 1.0.0, отдельные записи CVE начинают диапазон с 0.3.0. Обе версии описания сходятся в одном: переход на 1.1.0 или новее закрывает ошибки. Оценки CVSS взяты из записей CVE, поскольку сам бюллетень HashiCorp баллы не приводил.
Все три проблемы относятся к транспорту Streamable HTTP. Локальный однопользовательский режим stdio не затронут. Централизованную HTTP-конфигурацию для нескольких пользователей HashiCorp продвигала после выхода сервера в общую доступность в июне 2026 года. В намеренно включаемом stateless-режиме CVE-2026-16498, CVSS 10.0, возникала из-за того, что базовая MCP-библиотека не назначала уникальные идентификаторы сеансов, хотя кэш реквизитов Terraform полагался на них при разделении клиентов. В итоге токен одного пользователя мог применяться к последующим запросам других пользователей вне зависимости от переданных ими токенов. Корень ошибки довольно прозаичен: сервер ожидал от нижележащего MCP-слоя гарантии, которой в stateless-режиме не существовало.
CVE-2026-16496, CVSS 8.9, затрагивает stateful-режим, используемый по умолчанию в централизованных установках. Кэш искал Terraform-клиент только по идентификатору MCP-сеанса и не связывал его с токеном, создавшим этот клиент. Получив чужой идентификатор сеанса, атакующий мог вызывать инструменты через Terraform-клиент жертвы и обращаться к ресурсам в пределах прав её токена. Эту ошибку сообщил Juan Pablo Martinez Kuhn из Coinspect, две остальные HashiCorp нашла сама. CVE-2026-14869, CVSS 8.6, представляет собой SSRF: промежуточное ПО отклоняло переданный клиентом адрес Terraform в HTTP-заголовке, но пропускало то же значение в параметре запроса. Любой, кто мог достучаться до Streamable HTTP listener, получал возможность заставить сервер отправить настроенный bearer-токен на подконтрольный адрес, причём вход в систему не требовался.
Сравнивать оценки Veeam и HashiCorp напрямую нельзя: Veeam применяла CVSS 4.0, записи HashiCorp рассчитаны по CVSS 3.1. Практическая доступность тоже не совпадает с порядком баллов. CVE-2026-16498 с максимальными 10.0 работает лишь в stateless-режиме, который оператор включает вручную; CVE-2026-16496 с оценкой 8.9 затрагивает стандартный stateful-вариант централизованного сервера. Если немедленный переход на Terraform MCP Server 1.1.0 невозможен, доступ к Streamable HTTP listener следует оставить только доверенным пользователям, а идентификаторы MCP-сеансов хранить как секретные значения.
Django Software Foundation выпустила Django 6.0.8 и 5.2.17 4 августа 2026 года, перенесла исправления в основную ветку разработки и ветку релиз-кандидата Django 6.1. Единственная уязвимость высокой степени опасности, CVE-2026-15307, находится в GeoDjango. Пространственные запросы принимали значения str и dict, похожие на растры, и передавали их в GDALRaster. В зависимости от растрового драйвера это позволяло записать файл на диск либо инициировать сетевой запрос. Если файл попадал в каталог, откуда приложение позднее импортировало код, результатом могло стать удалённое выполнение кода. Описанный разработчиками путь через административную панель требует учётной записи сотрудника с правом просмотра зарегистрированной модели, содержащей пространственное поле. Исправление запрещает dict и строки, не являющиеся корректными значениями GEOSGeometry, в пространственных запросах; изменение нарушает обратную совместимость, хотя прямое присваивание полям модели по-прежнему принимает такие типы.
Оставшиеся ошибки Django получили умеренные и низкую оценки. CVE-2026-15920 — хранимая межсайтовая подстановка сценариев: небезопасное значение URLField отображалось в административной панели как ссылка, а код выполнялся после щелчка. CVE-2026-15830 позволяла вызвать отказ в обслуживании через глубоко вложенные объекты GEOMETRYCOLLECTION, доводившие GEOS до ошибки сегментации; теперь глубина ограничена 198 коллекциями. CVE-2026-15337 расходовала память через функцию check_for_language(), поэтому исправленная версия отбрасывает языковые коды длиннее 500 символов. Неподдерживаемые Django 5.1, 5.0 и 4.2 не проверялись и тоже могут содержать эти ошибки. При обновлении стоит отдельно пересмотреть права сотрудников, модели с пространственными полями, использование растров GeoDjango, значения URLField, вложенные геометрические коллекции и обработку языковых кодов.
Интерес атакующих к географическому коду Django уже подтверждён событиями 2026 года. В феврале была исправлена CVE-2026-1207 — SQL-инъекция в растровых запросах PostGIS. CrowdSec выпустила правило обнаружения 18 февраля, а первые атаки заметила 26 февраля; позднее продолжалось устойчивое сканирование сайтов в поисках установок Django с PostGIS. Для эксплуатации требовались backend PostGIS и пользовательский ввод, попадающий в конкретный запрос. Само зондирование могло определить тип приложения, но не взламывало его. Для новой CVE-2026-15307 этого также недостаточно: описанный маршрут требует учётной записи сотрудника с подходящим правом просмотра. Тем не менее проверки GIS- и raster-кода уже ведутся в реальной сети, поэтому отсутствие CVE-2026-15307, CVE-2026-15920, CVE-2026-15830 и CVE-2026-15337 в CISA KEV на 5 августа 2026 года не отменяет обновление до Django 6.0.8 или 5.2.17.[/final]
