紧急！Capacitor框架9.6分高危漏洞曝光，localStorage与身份令牌恐被一键读取

一条看似无害的链接竟能成为撬开整个移动应用的万能钥匙。如果你的 App 是用 Capacitor 开发的并且允许用户点开外部链接那么一个刚刚披露的严重漏洞可能正潜伏在数千万台设备上悄无声息地读取用户的登录凭证、身份令牌甚至直接调用手机的原生功能。这个被编号为 CVE-2026-103922 的漏洞在 CVSS v3.1 评分体系中拿到了惊人的 9.6 分妥妥属于严重级别。它影响的范围极广——所有使用存在缺陷版本的 Android、iOS 应用连同 Maven 和 Swift 的软件包发行渠道几乎无一幸免。问题究竟出在哪答案藏在 Capacitor 的 WebView 导航保护机制里。这套机制原本的职责是把守应用内网页跳转的大门每当 WebView 收到一个导航请求它会检查目标地址的协议和主机名确认来访者不是来自陌生站点。听起来挺周全对吧可惜它漏掉了一个关键细节——URL 的路径部分。打个比方保安查验了访客的身份却没注意对方要去的是哪间屋子。攻击者正是钻了这个空子。Capacitor 内部存在一个路径为 /capacitor_http_interceptor 的端点这个端点的设计用途是由原生层代为抓取远程内容。而导航保护机制偏偏对路径不设防于是攻击者可以构造一个指向该内部端点的链接并在请求中夹带任意远程地址。当用户在 App 的 WebView 里点开这个链接时Capacitor 的原生层便会兴冲冲地去抓取攻击者控制的页面内容再原封不动地送回 WebView。真正致命的地方在于这份恶意内容是在应用程序自己的合法源之下加载的。同源策略这道浏览器最重要的安全防线此刻形同虚设。恶意脚本因此获得了与应用本体平起平坐的地位。它能做什么localStorage 里存的敏感数据、HttpOnly 之外的可读 Cookie统统敞开大门任人翻阅。更可怕的是恶意脚本还能与 Capacitor 注册的各类插件交互——调用摄像头、读取文件、触发通知、操作设备数据具体能走多远完全取决于这个应用开通了哪些原生能力。身份验证令牌一旦落入攻击者手中后续的账号接管、数据窃取、横向渗透几乎顺理成章。更值得警惕的是利用这个漏洞并不需要什么高深技术唯一的门槛是让用户亲手点开那个恶意链接。这意味着凡是呈现用户可控链接的 Capacitor 应用都处在风险敞口之下聊天窗口里的消息、评论区里的回复、支持门户中的工单、社交动态里的分享、富文本文档中的引用、应用内浏览器打开的网页——每一个都是潜在的投递通道。还有一个让人哭笑不得的细节不少开发者得知消息后第一反应是禁用 CapacitorHttp 插件来止血。但 GitHub 官方公告明确指出即使禁用了这个插件内部代理处理程序依然会被调用等于关了前门后门照旧敞开。这种伪缓解状态反而可能延误真正的修复时机。那么哪些版本在带病名单上根据披露信息受影响范围横跨多个大版本6.0.0 至 6.2.2、7.0.0 至 7.6.9、8.0.0 至 8.3.5、8.3.5 至 8.4.3以及 8.5.0 至 8.5.1。覆盖面之大足见这是一次需要全员警觉的事件。应对之道其实并不复杂但每一步都不能省。开发团队应尽快将 Capacitor 升级到官方发布的修复版本随后重新构建 Android 与 iOS 两端应用并将新版本推送到各大应用商店——别忘了提醒用户更新停留在旧版的安装包依然是攻击者的猎物。官方此番的修复思路很清晰一是直接禁止框架导航到内部代理路径二是让代理处理程序只在 CapacitorHttp 启用时才对外服务三是拒绝响应文档类和主框架请求而正常的 fetch 与 XMLHttpRequest 调用不受影响既堵住了洞又不误伤业务。如果实在来不及升级临时方案也有可以编写自定义 Capacitor 插件专门拦截指向 /capacitor_http_interceptor 的导航请求从源头掐断攻击链路。与此同时无论是否升级都应该养成一个习惯——任何用户提交的 URL在渲染进 WebView 之前务必做严格的清理与白名单校验。移动安全的战场上同源信任向来是最后一道心理防线。而 CVE-2026-103922 用 9.6 分的代价提醒我们防线之外的每一个路径盲区都可能成为敌人悄悄潜入的侧门。趁补丁还在热着赶紧动手吧。