2026年8月4日、Myskの研究者たちは、設定されたプロキシをバイパスしてデバイスから直接トラフィックを送信するWebKitの3つのメカニズムの分析を発表しました。影響を受けたのは、Torブラウザを含むすべてのiOSブラウザで、Appleの独自サービスであるiCloud Private Relayも含まれています。プロキシが有効になっていると、インターフェースは他国を表示しますが、ウェブサイトは実際のIPアドレスと自宅のDNSリゾルバーを認識します。
これはパラノイア向けのエキゾチックな脆弱性ではありません。これは、プロキシを介して作業するすべての人が理解すべきアーキテクチャの原則を明示的に示しています：アプリケーションレベルのプロキシは、そのアプリケーションのネットワークスタックを通過するトラフィックのみを保護します。オペレーティングシステムや個別のシステムサービスが生成するすべてのものは、バイパスされます。
何が漏れているのか
調査は、プロキシブラウザPsyloのユーザーがDNSの漏洩について開発者に苦情を訴えた家庭の状況から始まりました。苦情の分析により、すべてWebKit自体に存在する3つの独立した漏洩チャネルが明らかになりました。
1. DNSプリフェッチ — 最も簡単で最も厄介なもの
メカニズム：<link rel="dns-prefetch">タグは、ブラウザにホスト名を事前に解決するように要求し、将来の読み込みを加速します。問題は、iOSのWebKitがそのような名前をデバイスの通常のDNS経路を通じて解決することで、プロキシを通じてではないことです。
デスクトップ版Safariは、Safari 5の頃からdns-prefetchをサポートしていますが、iOSはこのタグを無視していました — iOS 26.0（2025年9月）まで。そこでWebKitは、古い暗黙的な推測的DNSプリフェッチを削除する変更の一環としてこれを有効にしました（バグ285744）。
どのように悪用されるか：ページは、訪問者ごとにユニークなホスト名をこれらのタグに埋め込み、その後、リクエストが自分の権威DNSサーバーにどのように到着するかを単に観察します — 訪問者の実際のネットワークアドレスから。JavaScriptやユーザーとの相互作用は不要です。ページを開くだけで十分です。
2. WebAuthn関連のオリジンリクエスト — パスキーからの漏洩
このチャネルはiOS 18.0で登場しました。サイトがWebAuthnの資格情報（つまりパスキー）を要求すると、システムはhttps://<rpId>/.well-known/webauthnファイルを確認し、ドメインが指定されたリライイングパーティに実際に関連していることを確認します。
重要な点：この検証リクエストはブラウザのネットワークスタックからではなく送信されます。これは、オペレーティングシステムの資格情報サービスによって実行され、デバイスから直接HTTPSリクエストを送信します。ブラウザ内に設定されたプロキシは、これを認識しません（バグ268426）。
つまり、ページがパスキーのリクエストを開始するだけで、攻撃者のサーバーはあなたの実際のIPアドレスとの接続を受け取ります。
3. WebTransport — デバイスから直接QUIC
最新のチャネルです。new WebTransport(url)の呼び出しは、プロキシ設定をバイパスしてデバイスから直接QUIC接続を開きます。WebKitではWebTransportは長い間無効でしたが、2026年3月にiOS 26.4で公開されました（バグ260810および303453）。
誰に影響するのか
Appleは、iPhone上のすべてのブラウザがWebKitを使用することを要求しています。したがって、WebKitのプロキシAPIに依存するすべてのiOSブラウザが影響を受けます — すべてのiOSバージョンのTorブラウザと、調査が始まったPsyloを含みます。さらに、SafariとiCloud Private Relayも含まれます。
影響を受けないものは、VPNアプリです。これらはシステムレベルで動作し、デバイスのすべてのトラフィックを完全にカバーし、システムサービスによって生成されたトラフィックも含まれます。これが違いの本質です：システムトンネルには「バイパス」がありません。別の例外は、セキュリティレベルSilverのOnion Browserで、Lockdown Modeが有効になっている場合：これはWebTransportを介した漏洩に対して耐性があります。
開発者側からの反応はすでにあります。Psylo 1.3.1では、すべての3つのチャネルが閉じられました：アプリはdns-prefetchのヒントをブロックし（ページはもはや攻撃者が制御する名前を解決するようデバイスに強制できません）、WebTransportとWebAuthnはデフォルトで無効になっています — それらは個別のトグルで有効にできます。公開時点での情報によると、Appleは将来のアップデートで問題を修正する予定ですが、具体的な期限は発表されていません。
なぜ今になってこの問題が浮上したのか
ここでのタイムラインは示唆に富んでおり、別途分析する価値があります — なぜこの問題が以前に気付かれなかったのかを説明しています。
- 2024年9月、iOS 18.0 — WebAuthn関連のオリジンリクエストのメカニズムが登場。漏洩チャネルはほぼ2年間存在し、その間誰も議論していませんでした：パスキーのドメイン確認はセキュリティの要素として見え、アドレスを明らかにする手段とは見なされていませんでした。
- 2025年9月、iOS 26.0 — WebKitがモバイルデバイスでのdns-prefetchのサポートを追加。形式的には読み込み速度の最適化ですが、実際にはページがプロキシをバイパスして任意のDNS名にデバイスをリクエストさせることができるようになります。
- 2026年3月、iOS 26.4 — WebTransportが公開されます。3つ目のチャネル。
- 2026年8月 — 1人のユーザーからのDNS漏洩の苦情が、すべての3つのチャネルを一度に明らかにする調査につながります。
共通の要素：これらの機能のいずれも、非匿名化のチャネルとして意図されていませんでした。すべて3つはプラットフォームの通常の機能です：解決の加速、パスキーの確認、現代的な輸送です。アプリケーションレベルのプロキシモードと組み合わさることで初めて漏洩となり、そのため何年も誰もこの観点からテストしていなかったのです。
実践的な結論はシンプルで不快です：漏洩に関するニュースがないからといって、漏洩がないわけではありません。自分で定期的に確認する必要があり、誰かが分析を公開するのを待ってはいけません。
自分を確認する方法
研究者たちは公開スタンドを提供しました — leaks.psylo.app。これは3つのことを確認します：通常のHTTPSトラフィック（サーバーがどのIPとどのDNSリゾルバーを見ているか）、WebTransport、WebAuthn + dns-prefetchの組み合わせ。プロキシを有効にして開き、期待されるアドレスと結果を比較します。
基本的な衛生状態も確認する価値があります — あなたの作業環境でIP、DNS、WebRTCアドレスが一致しているかどうか。これまでにシステム的に行っていなかった場合は、私たちの分析から始めてください：プロキシのDNS漏洩を確認する方法。
実践的な結論：層が重要です
WebKitの話は、プロキシを介して作業する際に常に頭に置いておくべき一般的な原則の一例です。
- ブラウザのプロキシ ≠ デバイスのプロキシ。 アプリ内の設定は、アプリが自ら送信するトラフィックのみをカバーします。システムサービス、バックグラウンドプロセス、更新、プッシュ接続、そして今回明らかになったパスキーの組み込みサービス — すべてが独自の経路をたどります。
- 漏洩は「知られている」場所だけではありません。 WebRTCは長い間注目されていますが、それを防ぐ方法が見つかりました。そして、DNSプリフェッチやWebAuthnの確認は、誰も非匿名化のチャネルとして考えていなかったパフォーマンスとセキュリティの機能です。ブラウザの新機能は定期的に新しい回避策を生み出します。
- プラットフォームの更新は、静かにあなたの保護を破る可能性があります。 ここでは、日付によって文字通り見ることができます：DNSプリフェッチはiOS 26.0で「有効化」され、WebTransportはiOS 26.4で有効になりました。ユーザーは何も変更していないのに、漏洩の表面が自動的に増加しました。
これはマルチアカウントと自動化にとって何を意味するのか
複数のアカウントを持つ人やデータを収集する人にとって、ここでのリスクは抽象的なプライバシーではなく、完全に財務的なものです。プラットフォームの不正防止システムは信号を照合します：セッションが1つのIPを主張し、関連するリクエストが別のアドレスと自宅のリゾルバーから来る場合、これはアカウントを結びつけるか、セッションを疑わしいものとしてマークするための十分な理由です。
実践的な影響：
- モバイルブラウザでプロキシモードを使用している作業用マルチアカウントセッションを行わないでください。 プラットフォームが穴を閉じるまで、iOSのアプリケーション層は定義上信頼できません。
- トラフィックをシステム的に包み込む。 タスクがモバイル環境である場合、デバイスレベルでプロキシを立てるか、別のゲートウェイを介してルーティングする方が理にかなっています。ブラウザ内の設定に依存しないでください。
- OSとブラウザの大きな更新の後に組み合わせを確認してください。 四半期ごとに — 最低限。これをチェックリストに追加し、「何かがうまくいかないとき」に待たないでください。
- 使用していないものは無効にしてください。 パーシングやSMMのための作業プロファイルでWebTransportやWebAuthnはほぼ確実に必要ありません — これらを無効にすることで、3つの漏洩チャネルのうち2つを排除できます。
この時、IPの質は別の変数として残ります：データセンターのアドレスはASNによって自らを明らかにします。一般のユーザーのように見えることが重要なシナリオでは、レジデンシャルプロキシが機能し、モバイルアプリや最も厳しい不正防止のプラットフォームでは、モバイルプロキシが実際の携帯電話会社のIPを使用します。しかし、トラフィックの一部が物理的にそれをバイパスしている場合、どのプロキシクラスも救えません — まずは密閉性、その後にアドレスの質です。
結論
WebKitの3つのバグ — DNSプリフェッチ、WebAuthn関連のオリジンリクエスト、WebTransport — は、「プロキシが有効になっている」と「すべてのトラフィックがプロキシを通じている」は2つの異なる主張であることを示しました。iOSでは、これらの間のギャップは十分に広く、通常のウェブページがJavaScriptの行なしでTorブラウザの訪問者の実際のアドレスを知ることができました。
Appleが修正を準備している間、唯一の実行可能な戦略は、推測するのではなく確認することです。テストスタンドを開き、アドレスを比較し、余分なAPIを無効にしてください。そして、OSの大きなアップデートを、設定を再確認する必要があるイベントとして扱ってください。プライバシーとその幻想の違いは、しばしば「すべてのトラフィックが本当にそうか？」というタイミングを逃した1つの質問にあります。他の信号がアドレス以外に何を示しているかを理解することも有益です — これはブラウザフィンガープリンティングからの保護に関する資料で説明しています。