Как Meta AI support стал точкой захвата Instagram-аккаунтов

Meta раскрыла масштаб инцидента с High Touch Support: до 20 225 Instagram-аккаунтов могли быть затронуты через ошибку recovery flow.

Meta AI support и риск захвата Instagram-аккаунтов через AI-саппорт

Уязвимость Meta AI support в Instagram находилась в системе восстановления доступа High Touch Support. Она могла отправить ссылку для сброса пароля на email, не связанный с целевым аккаунтом. После сброса атакующий мог войти, если владелец не включил двухфакторную аутентификацию. Универсальный обход 2FA и «взлом всего Instagram» не подтверждены.

Факты проверены 20 июля 2026 года. По уведомлению Meta в офис генпрокурора штата Мэн, через эту ошибку могли быть затронуты до 20 225 Instagram-аккаунтов. Это верхняя граница оценки, а не число доказанных захватов.

Короткий ответ для владельца аккаунта: включите 2FA через приложение-аутентификатор, проверьте email и телефон для восстановления, завершите незнакомые сеансы и не подтверждайте вход с неизвестного устройства. Официальная проверка безопасности Instagram проводит пользователя по этим настройкам. Такие меры не исправляют ошибку платформы, но мешают атакующему завершить захват после сброса пароля.

Для команд, которые внедряют поддержку на основе ИИ, вывод шире. Помощник с правом менять параметры восстановления аккаунта становится частью контура безопасности. Его нельзя проектировать как обычный чат: решение о смене доступа должно проходить независимую проверку владельца.

Что именно подтвердила Meta 8 июня

Официальная страница Maine AG указывает 20 225 потенциально затронутых пользователей, включая 30 жителей штата Мэн. В карточке инцидента дата события указана как 17 апреля 2026 года, дата обнаружения — 31 мая 2026 года. Письмо Meta от 5 июня уточняет механику: уязвимость была в AI-assisted account recovery system для Instagram, которую компания называет High Touch Support, или HTS.

HTS должен был помогать пользователям, которые потеряли доступ к Instagram. Пользователь мог запросить ссылку для сброса пароля на свой email. По версии Meta, сам инструмент работал как задумано, но отдельная ветка кода не проверяла, совпадает ли введённый email с email аккаунта. Из-за этого ссылка могла уйти на адрес атакующего.

Meta отдельно оговаривает, что число 20 225 — верхняя граница. В эту оценку попали аккаунты, где пароль сбрасывали через support tool, 2FA не была включена, а доступ с высокой вероятностью получил посторонний. Часть обращений могла быть легитимной, поэтому корректная формулировка: «могли быть затронуты», а не «точно украдены все 20 225 аккаунтов».

Официальный кадр Meta о Meta AI support assistant для Facebook и Instagram
Официальный кадр Meta из анонса AI support assistant. В марте 2026 года компания описывала его как инструмент поддержки для Facebook и Instagram. Источник: Meta Newsroom

Где граница подтверждённых фактов

В этой истории легко уйти в громкий заголовок про «AI-чатбот, который взломал Instagram». Это неточно. Подтверждённый сценарий уже достаточно серьёзный: support-система с правом инициировать сброс пароля принимала email без нужной проверки. Но Meta не пишет, что внутренние системы были взломаны, и не утверждает, что все потенциально доступные данные реально просматривались.

Факт Статус на 8 июня 2026 года
Meta запускала AI support assistant для Facebook и Instagram Подтверждено официальным анонсом Meta от марта 2026 года: помощник должен помогать с проблемами аккаунта, включая сброс пароля и настройки профиля.
Количество потенциально затронутых аккаунтов Официальная карточка Maine AG указывает 20 225 человек, включая 30 жителей Мэна. Meta называет это верхней границей, а не точным числом доказанных захватов.
Период атаки и обнаружение Maine AG указывает дату события 17 апреля 2026 года, а дату обнаружения — 31 мая 2026 года. The Decoder описывает кампанию как почти семинедельную.
Механика сбоя По письму Meta, отдельная ветка кода не проверяла, связан ли email для reset link с Instagram-аккаунтом. Поэтому ссылка могла быть отправлена на неподтверждённый адрес.
Роль 2FA Meta пишет, что вход был возможен, если у владельца не была включена двухфакторная аутентификация. Универсальный обход 2FA как факт не подтверждён.
Какие данные могли быть доступны Meta перечисляет email или телефон, дату рождения, публикации, фото, видео, stories, личные сообщения, историю активности, профиль и связанные аккаунты. Компания пишет, что не знает, какие данные фактически были просмотрены.

Что Meta сделала после обнаружения

По уведомлению, Meta в день обнаружения отключила AI-assisted support tool, убрала уязвимую ветку из production и аннулировала уже выпущенные reset links, созданные через проблемный путь. Потенциально затронутые аккаунты перевели в обязательный security checkpoint: пользователям нужно было снова пройти аутентификацию и сбросить пароль через проверенные каналы.

Перед повторным запуском HTS Meta обещает исправить проверку email в точке входа Instagram recovery и проверить похожие flows восстановления аккаунтов на других платформах компании. Это правильный фокус: проблема не в том, что AI-бот «плохо понял просьбу», а в том, что privileged action оказался слишком близко к недоверенному пользовательскому тексту.

Почему это похоже на confused deputy

В безопасности есть термин confused deputy: привилегированный помощник выполняет действие в интересах атакующего, потому что не различает полномочия настоящего владельца и текст просьбы. В случае AI-саппорта роль такого помощника получает модель или агентный слой вокруг неё. Пользовательский текст выглядит как обычное обращение, но за ним может стоять попытка изменить email, пароль или другой фактор восстановления.

Связь с prompt injection здесь есть, но сводить всё к «модель поверила плохому промпту» слишком удобно. Сбой возникает там, где пользовательский текст, оценка риска и право выполнить действие оказываются в одной цепочке. В материале про безопасность агентских систем мы разбирали ту же логику: риск редко живёт только в модели. Он появляется на стыке прав доступа, внешнего контекста, инструментов и мониторинга.

Meta сама в мартовском анонсе писала, что новый помощник должен давать не только подсказки, но и решения. Для обычной поддержки это звучит привлекательно: меньше ожидания, больше автоматизации, доступность 24/7. Для восстановления аккаунта такая логика опасна, если модель может менять состояние без независимой проверки владельца.

Замаскированный скриншот диалога с Meta AI support assistant из материала Krebs on Security
Замаскированный скриншот из материала Krebs on Security. Содержимое запроса скрыто редакцией Toolarium, чтобы не публиковать инструкционные детали атаки. Источник: Krebs on Security

Что должны проверить команды с AI-саппортом

Главная инженерная ошибка в таких сценариях — считать AI-помощника внутренним доверенным актором. Он общается с внешним пользователем, читает недоверенный текст и может быть объектом социальной инженерии. Даже хорошая системная инструкция не заменяет контроль правилами вне модели.

  • Разделить режимы «советует» и «выполняет». Бот может объяснять процедуру, но изменение email, телефона, passkey или recovery code должно проходить через отдельный сервис проверки.
  • Дать боту минимальные права. Для восстановления аккаунта лучше начинать с режима только чтения и выдавать действия на запись только после независимой дополнительной проверки.
  • Не принимать пользовательский текст как доказательство владения. Скриншоты, уверенный тон, знание публичных данных и совпадение региона не должны заменять проверку старого канала связи или уже доверенного устройства.
  • Логировать каждое действие support-бота. В журнале должны быть видны запрос, вызванный инструмент, оценка риска, результат проверки правил и человек или сервис, который разрешил действие.
  • Выводить ценные аккаунты в отдельный поток. Короткие имена, аккаунты брендов, госструктур, знаменитостей и крупных компаний требуют ручной эскалации или более строгого восстановления.
  • Тестировать агентный слой, а не только модель. Prompt injection, roleplay, подмена контекста, конфликт целей и ошибки инструментов должны проверяться как единая система.

Смежный пример — история с Gemini API keys в Google Cloud: когда слабое место находится не в модели, а в контуре доступа, «AI-функция» быстро становится проблемой безопасности. А в пользовательских продуктах Meta этот контур особенно чувствителен: компания параллельно продвигает приватные AI-сценарии, включая Incognito Chat для Meta AI в WhatsApp, и любое recovery-действие рядом с личными сообщениями требует отдельной проверки.

Как защитить Instagram-аккаунт от захвата

Пользователь не должен отвечать за дыру в сценарии поддержки платформы. Но владельцам заметных аккаунтов всё равно стоит снизить ущерб от похожих атак.

  • Включить 2FA через приложение-аутентификатор. Meta рекомендует этот способ как основной; SMS-код лучше, чем отсутствие второго фактора, но зависит от безопасности номера.
  • Защитить почту, привязанную к аккаунту: отдельный пароль, 2FA, резервные коды, проверка правил пересылки и активных сессий.
  • Пройти проверку безопасности Instagram: сверить контакты восстановления, данные профиля и список активных сеансов, завершить незнакомые входы.
  • Для брендов и публичных аккаунтов заранее описать маршрут эскалации: кто имеет доступ, кто связывается с платформой, где лежат доказательства владения, как быстро отключается подозрительная активность.
  • Отслеживать неожиданные письма о сбросе пароля, новых устройствах и изменении профиля. В этой истории ранние уведомления могли быть единственным сигналом до потери доступа.
  • Если доступ уже потерян, открыть официальный раздел instagram.com/hacked и пройти восстановление с привычного устройства, не переходя по ссылкам из личных сообщений.

Почему это важнее одной ошибки Meta

AI-саппорт быстро становится способом сократить очередь в поддержке. Он отвечает быстрее человека, работает круглосуточно и может закрывать простые обращения без оператора. Но восстановление аккаунта не относится к простым обращениям, если в конце цепочки можно сменить фактор восстановления.

Инцидент с Meta AI support Instagram показывает практический предел агентности: модель можно подпустить к объяснениям и маршрутизации, но нельзя отдавать ей финальное решение о смене доступа без внешней проверки. Для пользователя это выглядит как один чат. Для инженера это должен быть набор строго разделённых уровней: разговор, оценка риска, проверка владения, разрешение действия, журнал и откат.

Иначе AI-помощник превращается в слишком услужливого оператора с правами администратора. Он не взламывает систему сам, но помогает атакующему пройти там, где обычный пользователь пройти не должен.

Источники

Читайте также

Telegram-канал @toolarium