Уязвимость tl;dv из-за ошибки настройки Google Firebase открыла посторонним данные о более чем 180 тыс. завершенных встреч и 80 тыс. пользователей сервиса. Хуже другое: исследователь смог заходить и в живые видеозвонки, так что AI-бот для протоколов внезапно оказался удобным шпионом на чужих переговорах. Для компаний, которые уже пустили в Zoom, Meet и Teams целый парк таких ассистентов, это не экзотика, а вполне рабочий сценарий утечки.
О проблеме сообщает Dark Reading. Исследователь под ником BobDaHacker еще в конце января заметил, что обычный пользователь tl;dv после входа в сервис получает session ID, с которым можно обращаться к Cloud Firestore на бэкенде продукта и запрашивать данные не только по своему аккаунту. Чужие транскрипты и записи напрямую не открывались, но коллекция meetings оказалась без нормальной tenant isolation: любой пользователь мог увидеть активные встречи, время их проведения, статус записи и email создателя звонка. На момент публикации 4 августа 2026 года изданию не удалось получить ответ от tl;dv, а проблема, по словам автора материала, оставалась неустраненной.
С технической точки зрения история почти обидная. BobDaHacker говорит, что Google в документации к Firestore отдельно предупреждает: security rules надо настраивать сразу, иначе база останется слишком открытой. По его оценке, здесь хватило бы нескольких строк правил, которые ограничили бы чтение данными внутри организации или tenant'а. Для разработчиков это неприятное напоминание: уязвимость tl;dv не про хитрый zero-day, а про базовую дисциплину конфигурации, которую команды часто откладывают на потом, особенно когда продукт быстро растет и сроки важнее скучной настройки доступа.
Дальше начинается самое неприятное. Получить сведения о встрече еще не значит автоматически войти в нее, но в своих тестах исследователь утверждает, что попадал в чужие созвоны примерно в 80% случаев. Иногда встреча и вовсе была открыта публично. В остальных случаях срабатывала старая добрая социальная инженерия: если попроситься в звонок под видом AI-ассистента, многие организаторы просто пропускают такого участника. Среди примеров — крупный звонок в Google Meet, который проводил малайзийский институт подготовки управленческих кадров при Министерстве образования. По собранным данным, сервис используют десятки госведомств, крупные университеты и корпорации; сам tl;dv на сайте пишет о более чем 2 млн пользователей и упоминает среди клиентов Salesforce, Forbes и Cloudflare.
При разборе уже завершенных звонков картина оказалась не лучше. BobDaHacker нашел более 180 тыс. записей о встречах, относящихся к более чем 80 тыс. аккаунтов. Среди них были созвоны структур из 23 стран с доменами .gov, а также встречи крупных компаний и университетов, включая HubSpot, японского девелопера Mitsui Fudosan, Калифорнийский университет в Беркли и Токийский университет. Отдельно исследователь взял выборку из более чем 27 тыс. meeting ID, проверил их на публично доступные следы и обнаружил свыше 1 тыс. случаев, где наружу торчали email приглашенных и тексты звонков. В этом списке оказались, например, встреча в Министерстве цифровой трансформации Украины и звонок правительства штата Сан-Паулу с природоохранными группами.
Здесь важен нюанс. По словам исследователя, из примерно 70 тыс. встреч, которые он просмотрел через REST API, публичный доступ к контенту был включен только примерно у 1 тыс. Значит, значительная часть прямой утечки зависела не только от Firestore, но и от того, как сами пользователи настраивали приватность. И это, пожалуй, худшая часть истории для бизнеса: даже если основная проблема чинится несколькими строками правил, привычка пускать ботов для заметок по умолчанию и не смотреть на политики шаринга делает ущерб намного шире. Бот для заметок давно перестал быть безобидным секретарем; это участник коммуникационного контура с доступом к видео, аудио, календарям и контактам.
Дополнительный штрих к картине — еще одна находка BobDaHacker. Исследуя поддомены tl;dv, он наткнулся на внутреннюю игру с сеткой чемпионата мира под названием Too Long; Didn’t Score. Ее API без аутентификации отдавал данные 42 сотрудников: имена, адреса электронной почты и пользовательские ники. Сам по себе это не главный эпизод истории, но как индикатор инженерной гигиены сигнал звучит нехорошо. Когда наружу торчит и клиентский контур, и внутренний мини-сервис, разговор уже не об одной неудачной настройке, а о том, как в компании вообще устроен контроль за поверхностью атаки.
Для разработчиков и ИБ-команд вывод практический. Любой AI-notetaker стоит учитывать как привилегированную интеграцию, а не как удобный плагин для протокола: проверять Firestore rules и tenant isolation, ограничивать перечень разрешенных ботов, выключать публичный шаринг по умолчанию и требовать ручного подтверждения незнакомых участников на встречах. Рынок AI-помощников для встреч растет быстрее, чем культура их проверки, и уязвимость tl;dv показала это слишком наглядно: один забытый слой правил превращает сервис для конспектов в инструмент разведки по чужим переговорам; подробнее об инциденте — в материале .