會原 
Shizukuに暗雲が到来していると話題です。GoogleのADB担当者が示した案が実装されれば、rootなしで動く便利ツール勢にちょっと痛い変更になるかもしれません。
発端は、Google Issue Trackerで議論されている機能要望です。AndroidのADBデーモン「adbd」が待ち受けるネットワークインターフェースやIPアドレスを指定できるようにしてほしい、という内容ですね。
ところが議論の中で、GoogleのADB担当者が別の方向性を問いかけました。localhost（端末自身を示す接続先）からadbdへ接続する仕組みが、アプリの権限昇格に悪用された例もあるとして、adbdの待ち受け先をWi-Fiのネットワークインターフェース「wlan0」だけに固定してはどうかという内容です。待ち受け先を「選べるようにする」どころか、常に一つへ絞る方向です。これだとちょっと話が変わってきますね。
この方式では、少なくとも127.0.0.1を使うループバック接続が待ち受け対象から外れます。つまりShizukuやlibadb-androidのほか、App ManagerやaShell、Termuxを使った端末内ADBの機能や手順が影響を受ける可能性があるってことです。もっとも、実際の影響範囲は実装や各ツールの対応次第です。
そもそもShizukuが何かというと、root化していない端末でも、通常のアプリからADBのshellユーザー権限でシステムAPIを利用できるようにする仕組みです。ワイヤレスデバッグ経由で端末単体でも起動でき、対応アプリはShizukuを通じて、通常はPCからのADBコマンドが必要な操作を実行できます。プリインストールアプリの管理や隠し設定の変更など、「PCに毎回つなぐのは面倒だけどroot化はしたくない」層にはありがたい存在なんですよね。Android 11以降で端末単体から起動できる手軽さを、ループバック接続が支えています。
念のため補足すると、今回の案はadbdのネットワーク側の待ち受け先を巡るもので、PCとUSB接続する通常のADBを廃止する話ではありません。Shizukuには、root権限を使う方法やPCからUSB ADBで起動する方法もあるため、仮にループバック接続が塞がれても、Shizukuそのものが完全に使えなくなるわけではありません。
元の機能要望の背景には、無線ADBの相互認証を回避できるCVE-2026-0073があります。NVDによると、影響を受けるのはAndroid 14、15、16、16 QPR2です。影響を受ける端末で無線ADBの接続先へ攻撃者が到達できる場合、隣接ネットワークの攻撃者が、利用者の操作なしにshellユーザー権限（通常のアプリより強い権限）でコードを実行できる恐れがあります。これはなかなか怖い脆弱性です。
Android Security Bulletinでは、セキュリティパッチレベル2026-05-01以降で対処するとしています。
とはいえ、wlan0限定はあくまでGoogle Issue Trackerのコメントで、ADB担当者が問いかけた案にとどまります。Googleが正式な製品方針として発表したものではなく、実装が決まったわけでもありません。現時点ではまだまだ「Shizuku終了」と考えるには早すぎます。セキュリティと利便性の綱引きがどこに落ち着くのか、続報を待ちたいところです。
