はじめに

2026年4月30日、セキュリティ研究者（lowlevel.fun）が、Android 16でVPNのロックダウン設定をすり抜けてUDPパケットを送れる経路を公開しました。検証環境では、「Always-On VPN」と「VPN以外の接続をブロック」を有効にした状態でも、細工したアプリが実IPアドレスを外部サーバーに知らせることができたと報告されています。

この記事では、研究者が確認した条件、Googleへの報告経緯、GrapheneOSの修正、そして一般ユーザーが取れる判断材料を、一次資料に沿って整理します。

記事の基準日について：本記事の初出は2026年5月7日、改訂は2026年9月26日です。研究者の報告（2026年4月30日公開）とGrapheneOSのリリースノートは2026年9月26日に再確認しました。現行の各メーカー端末・最新ビルドでの修正状況は網羅的に確認できていません。

一次資料：

何が問題なのか：QUIC接続終了APIとsystem_server

問題の中心は、Android 16で追加されたregisterQuicConnectionClosePayloadという仕組みです。本来は、アプリのUDPソケットが強制終了されたときに、相手のQUICサーバーへ「接続を閉じる」フレームをOSが代わりに送るための機能です。

研究者の報告によると：

  • このBinderメソッドは、自動付与されるINTERNETとACCESS_NETWORK_STATEの権限だけで呼び出せる
  • 登録されたペイロードの中身がQUICの終了フレームかどうかは検証されない
  • ソケットが破棄されると、system_server（UID 1000）が物理ネットワーク（多くはWi-Fi）に直接バインドしたソケットからそのペイロードを送る
  • VPNのロックダウンはアプリのUIDに対して適用される一方、システムUIDはその制限の対象外のため、この送信はVPNトンネルを通らない

Android 16のQUIC関連VPN漏えいの経路図。通常のアプリ通信はVPNトンネルを通るが、登録されたペイロードはsystem_serverがWi-Fiから直接送信し、VPNを経由しない

図：研究者の報告に基づく概念図。問題は「OS側の処理がVPNトンネル外へ送信すること」で、VPN事業者側の暗号化や経路の問題ではありません。

研究者が確認した条件

研究者は次の環境で漏えいを確認したと報告しています。

  • 端末：Pixel 8
  • OS：Android 16（ビルド BP22.250321.011）
  • VPN：Proton VPN
  • 設定：Always-On VPN ＋「VPN以外の接続をブロック」（ロックダウン）
  • 経路：VPN接続中のWi-Fi（研究者は、VPN以外の物理ネットワークであればWi-Fiに限らないとしています）

成立条件と影響範囲の注意点

  • 細工されたアプリが端末上で動作する必要があります。 普段の通信が自動的にVPN外へ流れるという話ではなく、この仕組みを意図的に悪用するアプリが、選んだ宛先にUDPパケットを送れる、という問題です。
  • 機能はDeviceConfigのフラグで制御されており、研究者はAndroid 16 QPR1系以降のビルドで到達したと説明しています。他の機種・ビルド・メーカー版で同じように成立するかは、この報告だけでは確認できません。
  • 研究者自身も、端末ごとの影響は自分で用意した受信サーバーに対してPoCを実行して確かめるしかない、としています。

Googleへの報告経緯

研究者が公開した報告履歴（Disclosure timeline）では、次のように記載されています。

日付内容（研究者の記載による）
2026-04-12Android VRPへPoC付きで報告
2026-04-18Android Security Teamが「Won’t Fix (Infeasible)」、NSBC（Security Bulletinの対象外）としてクローズ
2026-04-18研究者が再検討を要請
2026-04-24判断は変わらず
2026-04-29公開の許可

つまり、研究者が公開した報告履歴では、その時点でWon’t Fix等の回答が記載されています。 研究者は記事冒頭で「どうやら彼らの脅威モデルには入っていないようだ」と書いていますが、これは研究者の受け止めです。Googleの恒久的な方針や、その後のアップデートでの扱いを示すものではありません。本記事の改訂時点（2026年9月26日）で、Google側の後続対応は網羅的に確認できていません。

GrapheneOSの修正

GrapheneOSは、2026050400リリースの変更履歴に次の項目を記載しています。

disable registerQuicConnectionClosePayload optimization to fix VPN leak

つまり、問題となる最適化機能そのものを無効化することで、この漏えいを修正したという扱いです。GrapheneOSを使っている場合は、このリリース以降のビルドに更新されているかを確認してください。

なお、GrapheneOS自身も機能一覧の「Improved VPN leak blocking」で、VPN漏えい対策の強化を最優先課題の一つとしつつ、追加で見つかった比較的軽微な問題があるため、完成した機能とはまだ考えていないと説明しています。GrapheneOSに切り替えればあらゆるVPN漏えいがなくなる、という意味ではありません。

GrapheneOSの概要はGrapheneOS完全ガイド2026も参照してください。

研究者が報告した暫定的な機能無効化策

研究者は、標準Androidでもこの機能をADB経由で無効化する方法を記事末尾で紹介し、検証に使ったPixel 8で効果を確認したとしています。ただし、研究者自身が次の制限を挙げています。

  • 自己責任で、影響を理解したうえで使うべきもの（研究者の警告）
  • 工場出荷時リセットで設定は消える
  • 将来のMainlineアップデートでフラグ自体が削除される可能性があり、恒久策ではない
  • すべてのアプリの「QUIC接続の丁寧な終了」も無効になる
  • 通常のアプリからは設定状態を確認できず、確実な確認方法はPoCを自分の受信サーバーに向けて実行することだけ

ADB操作に慣れていない方が、手元の端末で検証せずにこのコマンドだけを実行することはおすすめしません。具体的な手順と注意点は、研究者の記事の「Mitigation」節を直接確認してください。

ほかのVPN漏えいとの関係、ミックスネットとの違い

今回の問題は、DNSリークと同じく「本来VPNを通るはずの通信の一部がトンネル外に出る」タイプの問題です。VPNアプリは、OSが用意するVPNの仕組みの上で動くため、OS側の処理がトンネルを迂回すると、VPNアプリ単体では防げません。

今回の問題は、端末側の処理がVPNトンネル外へ通信する点にあります。ミックスネットによるトラフィック解析対策とは別の問題であり、NymVPN等への変更だけで解消するとは確認できていません。対策は、対象端末・OSビルドでの修正や機能無効化の有効性を確認して判断する必要があります。

ミックスネットや多段経路が扱うのは、トンネルを通った後の通信の「タイミングや量の相関」を難しくするという別の問題です。この違いはWyden議員がNSAに求めたトラフィック解析の論点の記事でも整理しています。

判断のためのチェックリスト

  1. OSを最新に保つ：GrapheneOSなら2026050400以降か確認する。標準Androidでは、メーカーの更新内容に本件の修正が含まれるかを確認する（2026年9月26日時点で本記事では未確認）
  2. 不要なアプリを入れない：本件は端末上で動作するアプリが悪用する経路です。提供元の不明なアプリを入れないことが、影響を受ける前提条件を減らします
  3. VPNが守る範囲を整理する：VPNは経路上の盗聴やIPの秘匿に役立ちますが、OS側の迂回や端末上の不正アプリまでは防げません
  4. 暫定策は検証とセットで：ADBによる機能無効化を使う場合は、研究者の記載する制限を理解し、自分の受信サーバーで効果を確認する

VPN一般の限界についてはVPNをやめて代替手段を探す【2026年版】も参考になります。

まとめ

  • 研究者は、Android 16のQUIC接続終了APIを悪用すると、ロックダウン設定のVPNでもsystem_server経由でVPN外へUDPパケットを送れると報告した（Pixel 8 / Android 16 / Proton VPNで確認）
  • 成立には細工されたアプリが必要で、他機種・他ビルドでの状況はこの報告だけでは確認できない
  • 研究者が公開した報告履歴では、2026年4月時点でGoogleの回答はWon’t Fix (Infeasible)と記載されている
  • GrapheneOSは2026050400で該当機能を無効化して修正した。研究者もPixel 8で確認した暫定的な無効化策を示しているが、制限がある
  • ミックスネット型VPNへの変更は、このOS側の迂回とは別の問題への対策であり、本件の解消は確認できていない

GrapheneOS端末を検討している方へ

p-cipher.storeでは、GrapheneOSをプリインストールしたPixel端末を取り扱っています。到着後は、GrapheneOSが本件の修正を含むビルド（2026050400以降）に更新されているかを確認し、以後もアップデートを適用してください。GrapheneOSでもVPN漏えい対策は継続中の取り組みであり、端末上のアプリの選び方など利用者側の対策も引き続き必要です。

→ p-cipher.storeでGrapheneOS端末を確認する