ルート権限不要でVPNロックダウンを突破——Android 12以降の推定91%の機種で実IPが漏洩する脆弱性が報告される

9月11日、セキュリティ研究者のsupuk.chが「Android NAT-T Keepalive Offload Bypasses VPN Lockdown: Device-Class Exposure Across Most Android 12+ Devices」と題した記事を公開した。Android 12以降のほぼ全機種において、通常アプリがVPNロックダウンを回避してデバイスの実IPアドレスを外部に漏洩させられる脆弱性が詳細に報告されている。

「常時接続VPN」と「VPNなしの接続をブロック」はAndroidが提供する強力なセキュリティ設定で、ユーザーや企業管理者がトラフィックをVPNトンネル外に出させないために使う機能だ。しかし今回の調査によれば、ルート権限もADBも特別な権限も不要で、INTERNETとACCESS_NETWORK_STATEという通常アプリが持つ権限さえあればこの保護を完全にバイパスできることが確認された。Pixel 8 Pro・Samsung・Nothingの3社の実機で再現しており、2026年9月11日の報告公開時点で最新のAndroid 16でも未修正のままだ。

なぜ「VPNロックダウン」が問題になるのか

AndroidのVPNロックダウン（正式名称：Always-on VPN with block connections without VPN）は、VPNが切断された瞬間でも一切の通信をブロックし、「素の」IPアドレスがインターネットに漏れることを防ぐ機能だ。企業のMDM（モバイルデバイス管理）環境や、プライバシーを重視する個人ユーザーが依拠する最後の砦とも言える。この保護が、コードを数行書くだけで突破できるとなれば、影響は無視できない。

攻撃の仕組み：公開APIを使ったバイパス

問題の核心は、Androidの公開API IpSecManager.UdpEncapsulationSocket と ConnectivityManager.createSocketKeepalive() の組み合わせにある。

NAT-T（NAT Traversal）とは、NATルーターを越えてIPsec通信を維持するための仕組みで、UDPポート4500を使ってキープアライブパケットを定期送信する技術だ。AndroidはこのNAT-Tキープアライブ処理をWi-Fiチップセットのファームウェアにオフロード（委譲）できる。オフロードされると、アプリが起動していなくてもチップが自律的にパケットを送信し続ける。

攻撃に必要なコードは以下のとおりだ。Play Storeで配布される一般アプリが持つ権限の範囲内で動作する：

IpSecManager.UdpEncapsulationSocket socket =
        ipSecManager.openUdpEncapsulationSocket();
SocketKeepalive keepalive = connectivityManager.createSocketKeepalive(
        network,
        socket,
        sourceAddress,
        destinationAddress,
        executor,
        callback);
keepalive.start(10); // 10秒間隔

この数行が実行されると、ConnectivityService → KeepaliveTracker → NetworkAgent → Wi-Fi HAL → ファームウェアという経路を経て、物理Wi-FiインターフェースからVPNを迂回してパケットが送出される。本来VPN保護下のトラフィックはVPN TUNインターフェースを経由して暗号化トンネルに流れるべきだが、このNAT-Tキープアライブ経路はVPNロックダウンポリシーを一切チェックしない。VPNが有効であっても、デバイスの実際の送信元IPアドレスが攻撃者の指定したエンドポイントに10秒ごとに送り続けられる。

根本原因：権限チェックが「消えた」経緯

この問題の根源は startNattKeepaliveWithFd() の設計経緯にある。もともと特権プロセス向けのRAW fdを使うAPIとして設計された関数が、公開の UdpEncapsulationSocket 経路へ転用される過程で、IpSecリソースの所有者検証が追加・実装されたものの後にリバートされ、現在は呼び出し元UIDのVPNポリシーを確認しないままオフロードを実行する状態になっている。

関連するキープアライブAPIが PACKET_KEEPALIVE_OFFLOAD 権限を要求するのに対し、このfd経由のパスは要求しない。この権限の非対称性はAndroid Automotiveのアクセス制御研究でも過去に指摘されていたが、VPNロックダウンバイパスとしての具体的な攻撃経路と影響範囲は今回初めて詳細に示された。

実機での確認：3社のデバイスで再現

研究者は以下の3台で動作を確認した：

Pixel 8 Pro（Android 16、ビルド CP1A.260505.005）：研究者管理のWi-Fiアクセスポイントでパケットキャプチャを実施。VPNロックダウン有効中に10秒間隔でUDP/4500パケットが物理ルーターに到達していることを記録した
Samsung SM-F966B（Android 16）：同じ公開APIパスで物理IPv4デフォルトゲートウェイへのWi-Fiスロット使用を確認。24時間32分にわたる継続的なリースを記録した
Nothing A059「Asteroids」（Android 16）：Qualcommハードウェア上で物理ゲートウェイ経路への接続を確認

漏洩する情報はデバイスの実際の非VPN送信元IPアドレスとタイミング情報であり、攻撃者が指定したUDP/4500エンドポイントに継続的に送信される。

影響範囲：Android 12以降の推定91%超のデバイス

Wi-Fiキープアライブオフロードの対応状況を出荷台数ベースで調査した結果、Qualcomm・MediaTek・Samsung Exynos・Google Tensor・Broadcom・HiSilicon・Marvellの7つのWLANファミリーがAndroid由来出荷台数の推定91.24%をカバーしており、これらすべてで本問題の影響を受けるとされている。

攻撃者側の要件をまとめると：

ルート権限：不要
ADB：不要
危険なパーミッション：不要
PACKET_KEEPALIVE_OFFLOAD権限：不要
必要なのは INTERNET と ACCESS_NETWORK_STATE のみ

ただし、F-DroidおよびIzzyOnDroidで4,679のアプリをスキャンしたところ、AndroidフレームワークのIPsec/IKE/NAT-T APIを直接使用するアプリは検出されなかった。現時点で実際に悪用するアプリが広く出回っている状況ではないが、APIが公開されている以上、将来的な悪用のリスクは排除できない。

現在の対応状況と取れる対策

記事では、Googleへの報告タイムラインや修正パッチの提供時期は明示されていない。2026年9月11日の記事公開時点で最新のAndroid 16（ビルド CP1A.260505.005）でも再現が確認されており、未修正の状態が続いている。

完全な修正が提供されるまでの現実的な対策として、記事では以下の点が示唆されている：

信頼できないソースからアプリをインストールしない（本攻撃は悪意あるアプリによる実行が前提）
企業環境ではMDMによるアプリ配布制限を徹底する
VPNロックダウンが絶対的な保護とは言えない点を前提にネットワーク設計を見直す

Googleがこの問題をどのように扱うかは今後の動向に注目したい。

詳細はAndroid NAT-T Keepalive Offload Bypasses VPN Lockdown: Device-Class Exposure Across Most Android 12+ Devicesを参照していただきたい。