Учёные создали ИИ-агента для поиска уязвимостей в Android

Учёные создали ИИ-агента для поиска уязвимостей в Android

Учёные создали ИИ-агента для поиска уязвимостей в Android

Учёные из Китая и Австралии представили систему A2 — ИИ-агента, который умеет находить уязвимости в Android-приложениях и даже создавать PoC-эксплойты на лету. По сути, это продолжение их предыдущей разработки A1, ориентированной на смарт-контракты, только теперь фокус на мобильных приложениях.

Авторы исследования — Цзыюэ Ван из Нанкинского университета и Лийи Чжоу из Университета Сиднея — утверждают, что A2 показывает впечатляющие результаты: 78,3% покрытия на тестовом наборе Ghera против 30% у статического анализатора APKHunt.

Более того, при проверке 169 реальных APK-файлов агент нашёл 104 уязвимостей нулевого дня, из которых 57 подтвердил автоматически с помощью PoC-эксплойтов.

Один из примеров — баг в приложении более чем с 10 миллионами установок. Речь идёт об уязвимости типа intent redirect: если приложение не проверяет, куда именно отправляется «интент» (сообщение с запросом действия), злоумышленник может подменить получателя и перехватить управление.

Главное отличие A2 от предыдущих решений в том, что система не просто ищет подозрительные места в коде, а сама же проверяет их на практике. Как поясняет Чжоу, A2 разбивает задачу на этапы — найти ключ, сгенерировать токен, обойти аутентификацию — и на каждом шаге подтверждает результат. Это сильно снижает количество ложных срабатываний, от которых страдают традиционные сканеры.

Любопытно и то, что A2 построен на коммерческих ИИ-моделях вроде OpenAI o3 и Gemini 2.5. Они распределены по ролям: планировщик, исполнитель и валидатор. Такой «оркестр» ИИ позволяет подойти к поиску уязвимостей так, как это сделал бы живой эксперт.

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

По словам Чжоу, мы стоим на пороге «взрыва» в этой области: одни будут использовать A2-подобные системы для защиты, другие — для атак. Адам Бойнтон из Jamf добавляет, что ценность A2 именно в том, что он переводит процесс из бесконечного потока «шумных» алертов в доказательную практику, где командам безопасности остаётся разбираться только с реальными рисками.

Код A2 и артефакты пока доступны только исследователям с институциональной аффиляцией — баланс между открытой наукой и ответственным раскрытием.

Миллионы серверов под угрозой: в NGINX обнаружили опасную уязвимость

В NGINX обнаружили новую 0-day уязвимость под названием nginx-poolslip. По предварительным данным, баг может позволить удалённо выполнять код на уязвимых серверах без аутентификации. Проблема затрагивает NGINX 1.31.0 — актуальную стабильную версию популярного веб-сервера.

Уязвимость обнаружил исследователь Vega из команды NebSec, публично о ней сообщили 21 мая 2026 года.

Согласно описанию, nginx-poolslip связана с внутренним механизмом управления памятью NGINX. Самое неприятное — заявлена возможность обхода ASLR, одной из базовых защит от эксплуатации ошибок памяти. Если обход действительно работает стабильно, это резко повышает шансы атакующего не просто уронить сервер, а выполнить свой код.

История выглядит особенно неприятно на фоне недавней уязвимости CVE-2026-42945 в ngx_http_rewrite_module, которую уже закрывали в версиях 1.31.0 и 1.30.1. Но, по данным NebSec, предыдущий патч не убрал саму поверхность атаки, а nginx-poolslip позволяет обойти прежние меры защиты.

На момент публикации у nginx-poolslip ещё нет идентификатора, а F5 и проект NGINX не выпустили официальный патч. NebSec заявляет, что следует процедуре ответственного раскрытия и опубликует технические детали только после появления патча.

Пока заплатки нет, администраторам советуют снижать риски вручную: следить за бюллетенями F5 и NebSec, ограничить доступ к административным интерфейсам, использовать WAF-правила, проверить включение ASLR, а также внимательно пересмотреть конфигурации с rewrite, if и set.

Масштаб проблемы серьёзный, NGINX используется как веб-сервер, обратный прокси, балансировщик и API-шлюз на огромном числе площадок.

RSS: Новости на портале Anti-Malware.ru