你打开了一个网站，iCloud Private Relay 亮着绿灯，Safari 地址栏一片祥和。然后你点击了“登录”——一个 Passkey 弹窗跳出来，你扫了一下 Face ID，进去了。一切如常。
但你的真实 IP 地址，已经在这个瞬间被网站看到了。
这不是钓鱼攻击，也不是系统被入侵。这是苹果 iCloud Private Relay 的架构级漏洞，由安全研究员 Tommy Mysk 和 Talal Haj Bakry 在 2026 年 8 月 4 日披露。他们发现，当用户使用 Passkey 进行身份验证时，WebAuthn 认证请求会绕过 Safari 和 Private Relay 的代理链路，直接从操作系统凭证服务发起 HTTPS 连接，将用户的真实 IP 暴露给目标服务器。
三个漏洞，一个根源
Mysk 和 Haj Bakry 是隐私浏览器 Psylo 的创始人。一切始于一个用户反馈：某些网站的 DNS 查询会从用户的真实网络发出，而非经过代理服务器。深入追踪后，他们挖出了 WebKit 引擎中三条绕过代理的路径。
第一条：DNS 预取，iOS 26.0（2025 年 9 月发布）起支持。网站通过 dns-prefetch 标签要求浏览器提前解析域名，WebKit 直接通过设备默认 DNS 路径发起查询，绕过了配置的代理和 Private Relay。
第二条：WebAuthn 相关源请求（Related Origin Requests），iOS 18.0 起引入。这是最严重的一条。当网站触发 Passkey 认证时，操作系统凭证服务会直接向该网站发起 HTTPS 请求，以获取 /.well-known/webauthn 路径下的验证文件。这个请求完全在浏览器之外执行，Private Relay 拦截不到。
第三条：WebTransport，iOS 26.4 起支持。这个新协议建立 HTTP/3 直连，同样绕过代理配置。
“简而言之：任何支持或假装支持 Passkey 的网站，都能在用户开启 iCloud Private Relay 的情况下看到其真实 IP 地址。”Mysk 和 Haj Bakry 在技术博客中写道。
TechCrunch 在独立测试中验证了这一漏洞。更令人担忧的是，由于 iOS 平台要求所有浏览器使用 WebKit 引擎，这个漏洞不仅影响 Safari，还影响所有基于 WebKit 的第三方浏览器，包括 Tor 浏览器 OnionBrowser。Mysk 已联系 Tor 项目组。
为什么最安全的认证方式，打穿了最隐私的保护
为什么 Passkey——这个被公认为“最安全的认证方式”——会成为 Private Relay 的致命漏洞？
技术根源：WebAuthn 的架构悖论
Passkey 的设计初衷无可挑剔：用公钥密码学替代传统密码，用户通过 Face ID 或 Touch ID 一键登录，不留密码暴露面。WebAuthn 标准由 W3C 和 FIDO 联盟联合维护，被广泛认为是认证领域的未来方向。
但问题出在实现层面。WebAuthn 的 Related Origin Requests 机制允许一个域名的 Passkey 在多个关联域名之间复用。为了实现跨域验证，浏览器需要从目标域名的 /.well-known/webauthn 路径获取一个 JSON 文件，确认该域名是否在信任列表中。这个验证请求由操作系统凭证服务直接从系统层面发起，不经过浏览器，不经过 WebKit 的网络栈，更不经过 Private Relay 的代理链路。
“因为请求是由操作系统凭证服务发起的，而不是由 Safari 发起的，所以它永远不会进入 Private Relay 的代理路径。”研究人员写道。“目标服务器无论如何都能看到设备的真实 IP 地址。”
这是一个架构层面的悖论：Passkey 为了安全，要求操作系统直接参与认证，但 Private Relay 的隐私保护恰好依赖于所有流量都经过 Safari 的代理链路。当安全机制和隐私机制在架构层面发生冲突，用户就成了夹缝中的受害者。
更值得警惕的是，攻击者甚至不需要真正部署 Passkey 功能。一个网站只需“假装”触发 Passkey 认证流程，即可诱导操作系统发起 WebAuthn 验证请求，从而获取用户真实 IP。这意味着用户无法通过“我不使用 Passkey”来规避风险。只要网站诱导，泄露就会发生。
为什么是现在：苹果隐私承诺的裂缝
苹果一直把隐私作为核心品牌叙事。“隐私是一项基本人权。”Tim Cook 在多个场合重复这句话。“What happens on your iPhone, stays on your iPhone”这句广告语几乎成为苹果的品牌图腾。
iCloud Private Relay 是这一承诺的标志性功能。当用户开启后，所有 Safari 流量经过两个独立中继跳转，确保没有任何一方——包括苹果自己——能同时看到用户的身份和访问目标。它被深度整合进 iCloud+ 订阅体系，而截至 2025 年，苹果跨平台付费订阅已突破 10 亿。
但这个漏洞揭示了一个尴尬的事实：苹果的隐私架构只覆盖了“浏览器内”的那一层。一旦认证流程由操作系统接管，整个隐私保护就形同虚设。更糟糕的是，苹果在 iOS 26 中主动启用了 DNS 预取，在 iOS 26.4 中加入了 WebTransport 支持，这些功能恰恰扩大了泄露面，尽管它们或许是出于性能和功能扩展的考虑。
Mysk 告诉 404 Media，他们向苹果报告后，苹果承认这个问题“情况严峻”（dire），但没有给出修复时间表，只同意让研究人员公开披露。这意味着，在苹果发布修复之前，所有 iCloud Private Relay 用户都暴露在风险之中。
影响范围：谁在裸奔
这个问题的覆盖面远超表面看到的程度。
首先，iCloud+ 用户基础庞大。苹果 2025 年宣布跨平台付费订阅突破 10 亿，其中 iCloud+ 是核心组成部分。每个 iCloud+ 订阅可以分享给最多 5 名家庭成员，这意味着受影响的范围以亿计。
其次，iOS 强制所有浏览器使用 WebKit 引擎，这意味着任何在 iOS 上运行且依赖代理连接保护 IP 的浏览器都受影响，包括 Tor 浏览器 OnionBrowser，以及所有企业级安全浏览器。
第三，研究人员在自己的 Psylo 浏览器上已经给出了解决方案。Psylo 1.3.1 默认禁用 WebTransport 和 WebAuthn，阻止 DNS 预取标签，同时允许用户按需开启。但这个修复方案也暴露了更大的问题：浏览器开发者无法修改 WebKit 的网络实现，只能通过缩小功能集来规避风险。
第四，VPN 用户不受影响。VPN 在系统层面建立隧道，加密所有流量，包括这些绕过浏览器的请求。但 Private Relay 的用户——那些信任苹果隐私承诺、以为一个开关就能保护自己的人——恰是风险最高的群体。
谁在修补苹果的漏洞
这条漏洞的发现者本身就是苹果生态的深度参与者。Mysk 和 Haj Bakry 开发的 Psylo 同样基于 WebKit，同样受此漏洞影响。他们的修复方案——默认禁用 WebTransport 和 WebAuthn——本质上是在用“砍功能”来弥补苹果的架构缺陷。
苹果的回应“情况严峻”不无道理。这不是一个可以简单打补丁的 bug。这是 WebKit 架构层面、跨越多个操作系统版本（从 iOS 18 到 iOS 26.4）的隐私设计缺陷。修复需要从操作系统层面重新设计 WebAuthn 和 WebTransport 的流量路由，使其纳入代理管控范围，这涉及 WebKit 核心网络栈的改造，绝非一朝一夕。
对于普通用户，在苹果修复之前，最务实的做法是：在涉及敏感操作的网站上，使用 VPN 而非仅依赖 Private Relay。这听起来反直觉，你花了钱订阅 iCloud+，开启 Private Relay，结果反而需要另一层保护。但这就是现实。
更大的问题在于：当一家公司把隐私作为核心品牌承诺，而它的隐私架构却在认证流程中留了一个结构性后门——这个后门不是黑客挖出来的，是架构设计本身决定的——那么，用户对“隐私 iPhone”的信任，还能经得起几次这样的“严峻”通报？
苹果的隐私盾牌，在 Passkey 这个最安全的认证方式面前，碎成了最讽刺的漏洞。
快报