Исследователь Johann Rehberger (блог Embrace The Red) рассказал на BlueHat Asia 2026 в Сингапуре о CVE-2026-65669. Это критическая уязвимость в Copilot для SQL Server Management Studio, которая позволяет повысить привилегии: владелец базы становится администратором всего SQL Server. Rehberger советует обновить установки.
Короткая суть: агенту дали инструменты для работы с базой, но границы «нельзя писать» оказались не настоящим ограничением, а подсказкой в системном промпте и регуляркой в коде. Найденные обходы позволяют выйти из «read-only» режима.
Почему «только чтение» не сработало
Copilot в SSMS исполняет запросы через соединение пользователя. Если учётка в Query Window это sysadmin, то и Copilot работает с правами sysadmin. Это первая проблема: права ассистента равны правам человека.
Вторая проблема в том, как именно запрещены изменения. В системном промпте Copilot сказано: «you are running in a read-only mode». В коде проверка построена на регулярных выражениях в классе LocalSqlExecutionAccessChecker. Это не разрешение на уровне SQL-сервера, а текстовый фильтр, который ищет в запросе слова вроде EXEC.
Регулярку можно обойти. Конструкция DECLARE @p sysname=‘sp_executesql’; EXEC @p N’DROP TABLE [Test];’ выполняет произвольный T-SQL. После этого «read-only» превращается в «read-write»: CREATE, INSERT, UPDATE, DELETE, DROP.
Дополнительно нашёлся инструмент RestoreVerifyBackupFile для проверки бэкапов, через который тоже проходил произвольный T-SQL. То есть у агента оказалось два независимых пути выполнить запись.
От утечки данных до перехвата подсказок
С правами sysadmin агент может утянуть содержимое таблиц наружу. Rehberger показал это через xp_dirtree: запрос читает строку таблицы, подставляет её в SMB-путь, и каждая строка приходит на сторонний сервер при попытке подключения.
Отдельная история — это промпт-инъекция через содержимое базы. Copilot читает схему, метаданные, T-SQL-файлы и подмешивает их в контекст. Вредоносные инструкции в файле могут изменить поведение ассистента у другого пользователя, который позже этот файл откроет.
db_owner становится sysadmin
В SQL Server есть расширенные свойства объектов, которые Copilot автоматически подхватывает. AGENTS.md задаёт инструкции для конкретной таблицы или колонки, CONSTITUTION.md действует на всю базу. Эти свойства добавляются через sp_addextendedproperty и попадают в контекст модели.
Критичный момент: чтобы прикрепить AGENTS.md к объекту, нужно разрешение ALTER на этот объект. Когда пользователь с более высокими правами позже откроет таблицу через Copilot, инструкции выполнятся от его имени. Цепочка атаки, которую показал Rehberger: db_owner через CONSTITUTION.md подбрасывает инструкции, Copilot читает их в контекст, инъекция обходит read-only через RestoreVerifyBackupFile, от имени жертвы выполняется T-SQL, добавляющий атакующего в sysadmin.
Итог: владелец одной базы стал администратором всего SQL Server.
Что проверить у себя
- Проверить, под какой учёткой открыт Query Window при работе с Copilot. Это те же права, что у ассистента. Для прод-баз использовать отдельную низкопривилегированную учётку.
- Отключить Copilot групповой политикой или административными настройками там, где он не нужен.
- Пересмотреть, кому выдано право ALTER на таблицы и схемы: через sp_addextendedproperty такой пользователь может влиять на поведение Copilot у других людей.
- Не полагаться на «read-only» режим ассистента как на ограничение доступа. Если агенту дан доступ к БД, границы должны быть на уровне разрешений SQL-сервера, а не в системном промпте или регулярках.
- Ограничить выбор модели, которую использует агент, и учитывать, что у разных моделей разная устойчивость к промпт-инъекциям.