В баг-трекере Google обсуждают, стоит ли запретить подключения ADB через петлевой адрес 127.0.0.1. С таким предложением выступил один из основных сопровождающих ADB после уязвимости CVE-2026-0073, закрытой майскими патчами безопасности Android. В нынешней формулировке ограничение сломает Shizuku, libadb-android, App Manager и запуск ADB прямо на телефоне через Termux. Решения пока нет: обсуждение открытое, а его участники предлагают компромисс в виде отдельного переключателя в разделе «Для разработчиков».
Предложение привязать adbd только к интерфейсу wlan0
Исходная заявка в баг-трекере Google касается узкой технической задачи: дать возможность выбирать, на каком сетевом интерфейсе демон adbd принимает подключения. Сейчас он доступен на всех интерфейсах сразу, поэтому привязка к одному конкретному заметно сузила бы площадь атаки.
Спорным оказался комментарий одного из основных сопровождающих ADB, сотрудника Google. Он предложил жёстко привязать adbd к интерфейсу Wi-Fi wlan0 и обосновал это тем, что подключения к localhost уже становились источником эксплойтов – через этот сокет приложениям удавалось повысить собственные привилегии.
Привязка исключительно к wlan0 бьёт не только по локальным подключениям. Вместе с ними отпадают ADB через VPN, ADB через Ethernet и часть нестандартных конфигураций, которыми пользуются разработчики.
После отклика сообщества сотрудник Google сообщил, что рассмотрит возражения и оценит соотношение риска и полезности функции. Официального анонса или готового решения пока нет.
Как устроено подключение ADB через адрес 127.0.0.1
Изначально ADB рассчитан на два устройства: на телефоне работает демон adbd, на компьютере – клиент adb. Схема ломается, когда компьютера под рукой нет, и тогда клиент запускают прямо на телефоне, чаще всего в эмуляторе терминала Termux. Клиент и демон оказываются на одной машине, а соединение между ними идёт через петлевой адрес 127.0.0.1.
Петлевой интерфейс (loopback) – зарезервированный сетевой интерфейс, через который система отправляет пакеты самой себе. В IPv4 ему соответствует адрес 127.0.0.1 и доменное имя localhost.
Поднять такое соединение можно двумя путями. Первый – классический ADB по TCP/IP на порту 5555; режим включается с компьютера, уже подключённого по кабелю:
adb tcpip 5555
Второй путь – беспроводная отладка, появившаяся в Android 11. В русской локализации это пункт «Отладка по Wi-Fi» в разделе «Для разработчиков»: телефон соединяют с рабочей станцией по коду подключения или QR-коду, и предварительное подключение по кабелю здесь не нужно.
On-device ADB – неофициальный термин сообщества. Так называют любую схему, при которой клиент adb и демон adbd работают на одном и том же телефоне без участия компьютера.
На этой схеме держится целая группа проектов с открытым исходным кодом:
- Shizuku – выдача приложениям привилегий уровня shell без прав root;
- libadb-android – библиотека для встраивания клиента ADB прямо в приложение;
- App Manager – управление установленными приложениями и их разрешениями;
- Canta – удаление предустановленных приложений;
- aShell – оболочка для выполнения команд ADB на самом устройстве;
- ShizuWall и ShizuCallRecorder – сетевой экран и запись разговоров поверх Shizuku.
Shizuku – посредник между обычным приложением и системными API. Служба запускается через ADB или root и принимает вызовы от приложений, выполняя их с правами shell (UID 2000) или root (UID 0).
Главное практическое преимущество схемы – привилегированные команды выполняются в дороге, без привязки к компьютеру, и при этом устройство не проваливает проверки Play Integrity, в отличие от полноценного root-доступа.
CVE-2026-0073 и майские патчи безопасности Android
Поводом для всей дискуссии стала уязвимость CVE-2026-0073 в adbd. Логическая ошибка в функции adbd_tls_verify_cert файла auth.cpp позволяла полностью обойти взаимную проверку сертификатов при беспроводной отладке.
По классификации Google это критическая уязвимость: удалённое выполнение кода из смежной сети от имени пользователя shell, без каких-либо действий со стороны владельца устройства. Исправление вошло в бюллетень безопасности Android, опубликованный : брешь закрыта на уровне патча 2026-05-01 для Android 14, 15, 16 и 16 QPR2, а сам компонент adbd обновляется через системные обновления Google Play.
Патч устранил конкретную ошибку, но не саму модель работы: adbd по-прежнему принимает подключения на всех доступных интерфейсах, включая недоверенные сети. Именно эту площадь атаки и предлагается сузить.
Три сценария, где вредоносное приложение бессильно
Возражения против запрета собраны в техническом разборе, который опубликовал автор одного из затронутых приложений. Основной довод: вредоносная программа не способна поднять локальное соединение ADB самостоятельно – каждый шаг требует ручных действий владельца телефона.
В обычной конфигурации демон adbd не запущен вовсе, а разрешение WRITE_SECURE_SETTINGS выдаётся только через ADB, так что попыткам эксплуатации просто неоткуда взяться. Если владелец включил «Отладку по USB» и беспроводную отладку, остаётся разовое сопряжение – код подключения виден только в настройках, и вводит его человек. В третьем сценарии, с ADB по TCP/IP, при попытке подключения на экране появляется запрос авторизации, и отказ закрывает вопрос.
Отсюда и вывод разбора: эксплуатация CVE-2026-0073 становится возможной лишь после того, как пользователь вручную включил отладку. Тут же проводится аналогия с другими опасными механизмами Android – выбором стороннего приложения-клавиатуры, выдачей прав в разделе «Специальные возможности» или назначением администратора устройства. Все они допускают злоупотребление, но от них не отказываются.
Переключатель для разработчиков вместо полного запрета
Компромисс, который обсуждают участники ветки, сводится к отдельному переключателю в разделе «Для разработчиков»: локальный ADB заблокирован по умолчанию, но его можно включить осознанно. Требований к такому переключателю два. Он должен переживать перезагрузку, иначе Shizuku теряет смысл, и его состояние не должно считываться сторонними приложениями, чтобы в банковских приложениях и играх не срабатывали блокировки.
Более жёсткий вариант того же подхода – снимать ограничение только с компьютера, по кабелю. Тогда включение локального ADB превращается в осознанно принятый риск, а автоматизировать его через выданные обманом разрешения уже не выйдет.
Обсуждение идёт на фоне проверки разработчиков, которую Google вводит для приложений, устанавливаемых вне магазинов. По официальному описанию программы, с сентября 2026 года требование регистрации приложений у проверенных разработчиков начинает действовать в Бразилии, Индонезии, Сингапуре и Таиланде, а в 2027 году распространяется дальше. В том же документе ADB назван штатным способом устанавливать непроверенные и изменённые приложения на собственные устройства – то есть тем самым запасным выходом, который сейчас и обсуждают ограничить.
Заключение
На сегодня локальный ADB работает как прежде: обсуждение остаётся на стадии комментариев в баг-трекере, сроков и официальных документов нет. Следить стоит не за датами, а за формой итогового решения – отдельный переключатель и полный запрет петлевых подключений дают принципиально разный результат для всех, кто пользуется Shizuku, Termux и построенными вокруг них приложениями. Тем, у кого есть собственный технический сценарий, имеет смысл описать его в ветке баг-трекера; повторять уже озвученные доводы не нужно, для этого есть кнопка +1.