Приложение, способное рисовать поверх других окон и писать в общее хранилище телефона, может подсунуть ИИ-агенту команду текстом, которого человек попросту не видит. А ещё через пару шагов та же программа получает возможность выполнять код уже на компьютере, который этим агентом управляет. Звучит как параноидальная фантазия, но именно это показали исследователи из Simon Fraser University, Китайского университета Гонконга, Шаньдунского университета и лаборатории Xingtu при китайской компании QAX.
Работа появилась на arXiv 1 июля, а 14 июля вышла обновлённая версия. Первый автор — Zidong Zhang, он подтвердил это изданию The Hacker News лично. Команда протестировала пять открытых фреймворков для управления телефоном через ИИ: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM и MobA. Из семи типов атак каждый фреймворк оказался уязвим как минимум к шести. The Hacker News проверило репозитории 17 июля и обнаружило, что проблемный код — пути к скриншотам, вызовы шелла, откат на broadcast-рассылку — по-прежнему сидит в основных ветках. CVE никому не присвоили, о реальных случаях эксплуатации Zhang не сообщает. Мейнтейнерам писали в частном порядке ещё до публикации — ответа не последовало ни от кого.
Первая и, пожалуй, самая грубая дыра — в AppAgent. Там вывод модели напрямую подставляется в команду
Вторая атака построена на гонке файлов — классическом TOCTOU. Между моментом, когда телефон делает скриншот, и моментом, когда агент его забирает, проходит время, и за это время можно подменить картинку. У каждого фреймворка своя логика: Open-AutoGLM сначала выполняет
Третий вектор — подсознательный текст. Буквы рисуются с крайне низкой непрозрачностью, невидимые глазу, но читаемые моделями компьютерного зрения. При тестировании текста с прозрачностью 2% на двадцати попытках GPT-4o, Claude Opus 4.5, Gemini 3 Pro и GLM-4V показали результат 20 из 20. Слабее всех оказалась AutoGLM-Phone — компактная 9-миллиардная модель, работающая прямо на устройстве: 18 из 20. Все шесть протестированных моделей читали невидимый текст как минимум в 18 случаях из 20. Интересный момент: увеличение прозрачности почти не меняет результат — модели и так работают на пределе своих возможностей распознавания, у них попросту нет того порога восприятия, который есть у человеческого глаза.
Четвёртая атака эксплуатирует особенности самого железа. У экранов со скруглёнными углами и вырезами под камеру буфер кадра остаётся прямоугольным, так что часть пикселей рендерится в «скрытых» зонах под рамкой — и всё равно попадает в скриншот. У Pixel 4 в одном из углов нашлось около 78 пикселей скрытой ширины — этого достаточно для короткой команды. Все пять агентов успешно считывали payload, спрятанный именно там. Вывод исследователей звучит неутешительно: простого программного решения не существует, маскировка углов — лишь костыль для проблемы, заложенной в самом железе.
Пятая уязвимость касается служб специальных возможностей. Через них можно наложить поддельный экран входа поверх настоящего приложения, вынудив агента ввести учётные данные пользователя в фейковый интерфейс. Ни один из пяти агентов не заподозрил подвоха за сто попыток — в отличие от человека, который скорее насторожится при неожиданном запросе пароля.
Шестая атака бьёт по каналу связи между агентом и телефоном — там, где его попросту нет как такового. Агентам не хватает санкционированного способа вводить текст, поэтому они используют отладочные инструменты не по назначению. Open-AutoGLM кодирует набранный текст в base64 и рассылает его через implicit-broadcast
Седьмая атака — перехват текста через службы специальных возможностей: там, где у злоумышленника есть такой доступ, событие
Отдельно, как теоретическое расширение, а не измеренный результат, исследователи описали восьмой вариант — стеганографию через каналы цветности изображения. Payload прячется не в яркости, а в цветовых компонентах картинки, и для этой атаки вообще не нужно устанавливать вредоносное приложение: злоумышленник встраивает команду в обычную фотографию, а собственный агент жертвы сфотографирует экран и раскодирует её, просто читая мессенджер. Это единственный из всех вариантов, не требующий установочного шага.
Все атаки требуют выполнения нескольких условий: на устройстве уже должно быть установлено приложение, агент должен находиться в процессе выполнения задачи, а USB- или беспроводная отладка — быть включена. Речь идёт исключительно про открытые инструменты для разработчиков, а не про фирменных ассистентов вроде Bixby от Samsung или XiaoAi от Xiaomi. Платформа iOS вообще осталась за рамками исследования.
Существующие защиты закрывают проблему лишь частично. MobA передаёт скриншоты потоково через
Показательна судьба подтверждающих запросов как метода защиты. Open-AutoGLM действительно выводит подтверждение перед «чувствительными» действиями. Но решает, что считать чувствительным, сама модель — а атаки на восприятие вроде подсознательного текста, подмены интерфейса или подмены скриншота манипулируют этим решением ещё до того, как срабатывает запрос подтверждения. Против перехвата broadcast и снятия текста через accessibility такая защита вообще бесполезна — там нет отдельного дискретного «действия», которое можно подтвердить: текст уже перехвачен.
Ни у одного из пяти проектов нет выделенного канала для сообщения об уязвимостях. The Hacker News не нашло опубликованной политики безопасности ни у одного из репозиториев. В самой статье указано, что первыми связались с Tencent и Alibaba. Исследовательские open-source проекты, судя по всему, попросту выпадают из зоны ответственности стандартных центров реагирования на инциденты безопасности.
Схожий паттерн — передача вывода модели напрямую в шелл — Microsoft уже документировала в мае для своего фреймворка Semantic Kernel. Результатом стали CVE-2026-25592, CVE-2026-26030 и выпущенный патч. Принцип, сформулированный Microsoft и прямо применимый здесь, звучит коротко: ваша LLM — не граница безопасности.
Стоит заметить, что раздел о связанных работах в этой статье не ссылается ни на Wu et al., которые ещё в мае 2025 года показали инъекцию через оверлейные окна против AppAgent и Mobile-Agent, ни на работу Ding et al. — литература по безопасности мобильных агентов в целом обойдена стороной. Собственный вклад авторов в том, что цепочка атаки продолжена дальше экрана — через файловую систему на сам хост-компьютер.
Масштаб проблемы иллюстрирует Open-AutoGLM — у проекта больше 25 тысяч звёзд на GitHub. Его README прямо инструктирует пользователей включить отладку по USB, установить сторонним способом ADB Keyboard и выдать ему доступ к вводу. Как отмечают исследователи, инструкция по настройке — это и есть значительная часть модели угрозы.
Работа появилась на arXiv 1 июля, а 14 июля вышла обновлённая версия. Первый автор — Zidong Zhang, он подтвердил это изданию The Hacker News лично. Команда протестировала пять открытых фреймворков для управления телефоном через ИИ: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM и MobA. Из семи типов атак каждый фреймворк оказался уязвим как минимум к шести. The Hacker News проверило репозитории 17 июля и обнаружило, что проблемный код — пути к скриншотам, вызовы шелла, откат на broadcast-рассылку — по-прежнему сидит в основных ветках. CVE никому не присвоили, о реальных случаях эксплуатации Zhang не сообщает. Мейнтейнерам писали в частном порядке ещё до публикации — ответа не последовало ни от кого.
Первая и, пожалуй, самая грубая дыра — в AppAgent. Там вывод модели напрямую подставляется в команду
adb shell input text {input_str} через subprocess.run(adb_command, shell=True), причём без всякой очистки. В коде есть частичная защита — убираются пробелы и одинарные кавычки, но точка с запятой, амперсанд, знак > и прочие управляющие символы шелла проходят свободно. Payload, запускающий calc.exe, срабатывал 20 раз из 20 против AppAgent, AppAgentX, Mobile-Agent-v3 и MobA. А тестовая строка test;pwd>rce_success в сквозном эксперименте записала рабочую директорию хоста прямо в файл. Вторая атака построена на гонке файлов — классическом TOCTOU. Между моментом, когда телефон делает скриншот, и моментом, когда агент его забирает, проходит время, и за это время можно подменить картинку. У каждого фреймворка своя логика: Open-AutoGLM сначала выполняет
screencap -p /sdcard/tmp.png, потом отдельной командой adb pull; Mobile-Agent-v3 пишет в фиксированный /sdcard/screenshot.png и делает паузу в 0,5 секунды между шагами; AppAgentX сохраняет файлы с меткой времени и растущим счётчиком шага — предсказуемая схема; у AppAgent путь к скриншотам по умолчанию в config.yaml вообще указывает на /sdcard. Замеры на ста прогонах показали разброс задержки от 50 до 500 миллисекунд, в среднем около 210 мс. Фоновый сервис, опрашивающий файл каждые 5-10 миллисекунд, успевает заблокировать его, перерисовать PNG и отпустить до того, как агент его заберёт. Подмена срабатывала от 19 до 20 раз из 20 против четырёх фреймворков из пяти. Отдельный трюк расширяет это окно ещё сильнее: невидимый оверлей сообщает агенту, что идёт «синхронизация по сети», и просит подождать три секунды — и модель послушно ждёт. Третий вектор — подсознательный текст. Буквы рисуются с крайне низкой непрозрачностью, невидимые глазу, но читаемые моделями компьютерного зрения. При тестировании текста с прозрачностью 2% на двадцати попытках GPT-4o, Claude Opus 4.5, Gemini 3 Pro и GLM-4V показали результат 20 из 20. Слабее всех оказалась AutoGLM-Phone — компактная 9-миллиардная модель, работающая прямо на устройстве: 18 из 20. Все шесть протестированных моделей читали невидимый текст как минимум в 18 случаях из 20. Интересный момент: увеличение прозрачности почти не меняет результат — модели и так работают на пределе своих возможностей распознавания, у них попросту нет того порога восприятия, который есть у человеческого глаза.
Четвёртая атака эксплуатирует особенности самого железа. У экранов со скруглёнными углами и вырезами под камеру буфер кадра остаётся прямоугольным, так что часть пикселей рендерится в «скрытых» зонах под рамкой — и всё равно попадает в скриншот. У Pixel 4 в одном из углов нашлось около 78 пикселей скрытой ширины — этого достаточно для короткой команды. Все пять агентов успешно считывали payload, спрятанный именно там. Вывод исследователей звучит неутешительно: простого программного решения не существует, маскировка углов — лишь костыль для проблемы, заложенной в самом железе.
Пятая уязвимость касается служб специальных возможностей. Через них можно наложить поддельный экран входа поверх настоящего приложения, вынудив агента ввести учётные данные пользователя в фейковый интерфейс. Ни один из пяти агентов не заподозрил подвоха за сто попыток — в отличие от человека, который скорее насторожится при неожиданном запросе пароля.
Шестая атака бьёт по каналу связи между агентом и телефоном — там, где его попросту нет как такового. Агентам не хватает санкционированного способа вводить текст, поэтому они используют отладочные инструменты не по назначению. Open-AutoGLM кодирует набранный текст в base64 и рассылает его через implicit-broadcast
ADB_INPUT_B64, который перехватывает ADB Keyboard — инструмент для автоматизации тестирования, спроектированный принимать текст от любого источника рассылки. ADB Keyboard, кстати, активно поддерживается, в апреле вышел предрелиз с исправлением под Android 16 — сам инструмент работает точно так, как задокументировано, проблема в том, что агенты используют тестовую инфраструктуру как продакшн-канал ввода. Mobile-Agent-v3 частично смягчает риск: буквы, цифры и знаки препинания ASCII отправляются через adb shell input text по белому списку, а не-ASCII символы идут по одному через broadcast ADB_INPUT_TEXT. У MobA всё хуже — там проверка text.isascii() выполняется на всей строке целиком, и достаточно одного эмодзи или буквы с диакритикой, чтобы всё сообщение целиком ушло через broadcast одним куском. Критическая деталь: любое приложение, подписавшееся на то же действие рассылки, получает этот payload — никакого разрешения для этого не требуется, и пользователь ни о чём не узнает. Седьмая атака — перехват текста через службы специальных возможностей: там, где у злоумышленника есть такой доступ, событие
TYPE_VIEW_TEXT_CHANGED отдаёт набранный текст открытым текстом, включая содержимое полей паролей, причём это касается всех пяти фреймворков. Отдельно, как теоретическое расширение, а не измеренный результат, исследователи описали восьмой вариант — стеганографию через каналы цветности изображения. Payload прячется не в яркости, а в цветовых компонентах картинки, и для этой атаки вообще не нужно устанавливать вредоносное приложение: злоумышленник встраивает команду в обычную фотографию, а собственный агент жертвы сфотографирует экран и раскодирует её, просто читая мессенджер. Это единственный из всех вариантов, не требующий установочного шага.
Все атаки требуют выполнения нескольких условий: на устройстве уже должно быть установлено приложение, агент должен находиться в процессе выполнения задачи, а USB- или беспроводная отладка — быть включена. Речь идёт исключительно про открытые инструменты для разработчиков, а не про фирменных ассистентов вроде Bixby от Samsung или XiaoAi от Xiaomi. Платформа iOS вообще осталась за рамками исследования.
Существующие защиты закрывают проблему лишь частично. MobA передаёт скриншоты потоково через
exec-out, минуя файл на устройстве — тем самым устраняя саму возможность гонки TOCTOU. Open-AutoGLM передаёт аргументы списком, а не склеенной строкой — единственный из пяти фреймворков, устойчивый к command injection на хосте. Но ни один из проектов не реализует обе защиты сразу. Рекомендации исследователей просты и не требуют изменений в самой модели: отказаться от shell=True в пользу списков аргументов, чтобы служебные символы шелла оставались просто текстом; передавать скриншоты потоком вместо записи и последующего чтения; ставить разрешение уровня подписи на broadcast-каналы ввода или переходить на явные intent'ы; сверять foreground-активность до и после каждого действия и держать белый список пакетов на время задачи; применять коррекцию контраста к скриншотам перед обработкой моделью — хотя это лишь частичное решение. Показательна судьба подтверждающих запросов как метода защиты. Open-AutoGLM действительно выводит подтверждение перед «чувствительными» действиями. Но решает, что считать чувствительным, сама модель — а атаки на восприятие вроде подсознательного текста, подмены интерфейса или подмены скриншота манипулируют этим решением ещё до того, как срабатывает запрос подтверждения. Против перехвата broadcast и снятия текста через accessibility такая защита вообще бесполезна — там нет отдельного дискретного «действия», которое можно подтвердить: текст уже перехвачен.
Ни у одного из пяти проектов нет выделенного канала для сообщения об уязвимостях. The Hacker News не нашло опубликованной политики безопасности ни у одного из репозиториев. В самой статье указано, что первыми связались с Tencent и Alibaba. Исследовательские open-source проекты, судя по всему, попросту выпадают из зоны ответственности стандартных центров реагирования на инциденты безопасности.
Схожий паттерн — передача вывода модели напрямую в шелл — Microsoft уже документировала в мае для своего фреймворка Semantic Kernel. Результатом стали CVE-2026-25592, CVE-2026-26030 и выпущенный патч. Принцип, сформулированный Microsoft и прямо применимый здесь, звучит коротко: ваша LLM — не граница безопасности.
Стоит заметить, что раздел о связанных работах в этой статье не ссылается ни на Wu et al., которые ещё в мае 2025 года показали инъекцию через оверлейные окна против AppAgent и Mobile-Agent, ни на работу Ding et al. — литература по безопасности мобильных агентов в целом обойдена стороной. Собственный вклад авторов в том, что цепочка атаки продолжена дальше экрана — через файловую систему на сам хост-компьютер.
Масштаб проблемы иллюстрирует Open-AutoGLM — у проекта больше 25 тысяч звёзд на GitHub. Его README прямо инструктирует пользователей включить отладку по USB, установить сторонним способом ADB Keyboard и выдать ему доступ к вводу. Как отмечают исследователи, инструкция по настройке — это и есть значительная часть модели угрозы.