Вышла Datasette 1.0a38 — бесплатный инструмент с открытым кодом, которым публикуют и просматривают таблицы данных прямо в браузере. В релизе закрыта уязвимость: при определённой настройке посетитель с правом смотреть публичные таблицы мог вытащить содержимое приватных из той же базы. Разбираем, как это работало, кого задевает и что делать.
Как чужой запрос читает закрытую таблицу
SQL — язык, на котором задают вопросы базе данных. SQL-инъекция — приём, когда вместо обычного значения в запрос подсовывают кусок этого языка, и база выполняет его как команду.
В Datasette это выглядело так. Пользователь имеет доступ к публичной таблице — это законно. Но в форму запроса он вписывает конструкцию, которая обращается к соседней приватной таблице в той же базе. Проверка прав срабатывала на уровне таблицы, к которой человек обратился явно, а до второй таблицы, упомянутой внутри запроса, не доходила.
Итог: права настроены верно, а данные всё равно видны. Именно поэтому такие ошибки опасны — со стороны администратора всё выглядит правильно.
Что нужно сделать администратору
Первое — обновиться: до 1.0a38 в ветке 1.0 или до 0.65.3, если вы на старой.
Второе — проверить разрешение execute-sql. Оно позволяет писать в интерфейсе произвольные SQL-запросы. Для базы, где рядом лежат публичные и приватные таблицы, это разрешение стоит снять со всех, кому оно не нужно по работе. Обновление закрывает конкретную дыру, а снятое разрешение убирает целый класс подобных проблем.
Третье — разнести данные по разным базам. Приватные таблицы в одном файле, публичные в другом: тогда неверная настройка прав не приводит к утечке.
Кого это на самом деле касается
Уязвимость срабатывает при совпадении трёх условий: публичные и приватные таблицы лежат в одной базе, доступ к ним идёт через один сервер Datasette, и у пользователей есть право выполнять SQL. По оценке самого автора Datasette, такая конфигурация встречается редко.
Если вы просто открываете чужие опубликованные таблицы или не смешиваете открытые и закрытые данные в одном файле — вас это не задевает.
Урок, который переносится на ИИ-агентов
За этой историей стоит общий принцип: право читать одно не должно давать возможность прочитать другое. Он важен не только для баз данных.
Ровно та же логика работает с ИИ-агентами. Агент с доступом к одной папке или одному чату не должен через хитрый запрос добраться до соседних. Мы разбирали это на практике в материале про изоляцию личных чатов с OpenClaw-ботом. Смежные темы — голосовой агент Hermes и модель Ling-3.0-flash.
Проверьте это сегодня, если у вас свой Datasette
Порядок действий короткий:
- обновите Datasette до 1.0a38 или 0.65.3;
- посмотрите, у кого включено
execute-sql, и оставьте его только тем, кому оно нужно; - проверьте, не лежат ли приватные и публичные таблицы в одном файле базы.
Если сервером занимается кто-то другой, перешлите ему этот список — формулировок достаточно, чтобы он понял задачу за минуту.
А общий вывод годится и без Datasette: разбирая права доступа в любом сервисе, спрашивайте не «кто сюда войдёт», а «что человек сможет отсюда достать».
Источник: Release datasette 1.0a38, Simon Willison, 6 августа 2026.
Другие случаи, когда агент вышел за рамки ожидаемого: инцидент с Hugging Face и кибератака ИИ-агента в июле 2026.