iOS 沙盒逃逸:worse_query 如何威胁你的加密钱包?

从 PoC 到可侧载工具，一次移动端安全边界的现实压力测试

Agent Infrastructure Lab｜探索全球金融与数字基础设施

一、一个漏洞，为什么让加密资产行业如此紧张？

2026 年 11 月 8 日，安全研究者 forcequitOS 公开了一个名为worse_query的 iOS 沙盒逃逸 PoC。

两天后，Binance 发布安全提醒，指出部分 iOS 版本存在应用间数据隔离风险。如果恶意应用利用这一问题，可能读取其他应用的本地文件，涉及加密钱包的助记词、私钥和登录凭据。

这件事很快引起了加密资产安全社区的关注。

但真正值得关注的，不只是一个漏洞被公开，而是它在短时间内出现了三个变化：

研究者公开了沙盒逃逸 PoC；

开发者将其封装为可以侧载安装的文件管理工具 WQ Files；

加密安全机构开始提醒用户关注本地钱包数据泄露风险。

这意味着，讨论已经不再局限于漏洞原理，而是开始进入工具化和实际风险评估阶段。

二、worse_query 到底突破了什么？

iOS 的安全设计有一个重要基础：应用沙盒。

每个应用通常运行在自己的容器中，拥有独立的数据目录。正常情况下，应用 A 无法直接读取应用 B 的私有文件。

例如，钱包 A 保存自己的数据库，社交应用 B 保存自己的聊天记录，文件管理器 C 只能访问系统允许其访问的文件。这种隔离机制能够限制应用之间的数据访问，避免一个应用轻易影响其他应用。

而 worse_query 的问题在于：它展示了一种突破应用容器隔离边界的能力。

根据 forcequitOS 在 GitHub 发布的 README，worse_query 可以访问以下目录：

Application Containers：应用数据容器

AppGroup Containers：应用组共享容器

PluginKitPlugin：插件相关容器

InternalDaemon：内部服务相关容器

SystemGroup：iOS 27 上的部分系统组目录

这里最关键的是 Application 和 AppGroup 两类目录。前者涉及不同应用各自的数据空间，后者则是应用及其扩展之间共享数据的空间。

这不是传统意义上的越狱。它不意味着攻击者获得了完整系统控制权，也不意味着能够任意读取所有系统文件。

三、从 PoC 到工具：WQ Files 让问题发生了什么变化？

如果 worse_query 只停留在 GitHub 上的一段研究代码，它的实际影响还相对有限。

但 11 月 9 日，开发者 Christoph Kolbicz 发布了基于 worse_query 的工具：WQ Files（Worse Query Files）。

它不是一个传统文件管理器，而是一个建立在沙盒逃逸技术之上的 iOS 文件浏览和应用数据管理工具。

根据其公开 GitHub 项目及 Release 说明，WQ Files 可以实现：

浏览不同应用的数据容器；

浏览 App Group 和扩展容器；

查看应用缓存和临时文件；

备份、恢复和清理应用数据；

编辑部分文本和 Plist 文件；

将备份通过 AirDrop 传输。

其项目说明声称，无需越狱，也不需要内核漏洞利用。

更重要的是，WQ Files 已经提供可侧载安装的 IPA 发布版本。

不过，它并非安装后就能在所有设备上运行。项目说明显示：

面向 iOS 27；

已测试环境为 iOS 27.0.1；

需要侧载工具保留 App Group entitlement；

如果重新签名时丢失相关 entitlement，工具会提示缺少 App Group。

此外，部分系统目录只能列出，不能直接读取；某些文件也受文件所有权和权限限制。

这说明两个不同层面的事情：原始 PoC 已经被封装成可供用户操作的工具；但工具能够浏览其他应用的数据，不代表它能够读取所有文件，更不代表所有文件都可以被解密和利用。

四、攻击成立需要什么条件？

这里需要纠正一种容易产生的误解：并不是只要 iPhone 上安装了一个普通应用，攻击者就可以自动读取所有钱包数据。

结合公开 PoC 和 WQ Files 的实现说明，至少需要关注三个条件。

1. 应用必须进入设备运行环境

攻击者需要让相关应用被安装并运行。侧载 IPA、企业签名应用以及不可信分发渠道，都可能成为入口。

这也是为什么攻击者可能伪装成免费文件管理器、手机清理工具、AI 功能解锁工具、加密货币辅助应用，或游戏插件和机器人工具。

企业签名能够解决应用分发和安装层面的部分要求，但并不代表应用本身可信。

2. 应用需要满足 App Group 条件

worse_query 的 README 明确要求使用者为应用配置 App Group 容器。WQ Files 的发布说明也表明，侧载工具必须保留 App Group entitlement。

因此，攻击者并不是仅凭一个普通 IPA 文件就能无条件获得全部访问能力。需要结合具体的签名、entitlement 和漏洞利用条件判断。

3. 目标文件必须具备实际可利用性

这是最容易被忽略的一层。即使恶意应用能够访问钱包的数据目录，也不意味着可以直接拿到完整私钥。

最终能否造成资产损失，取决于钱包的数据存储方式：

助记词是否以明文形式写入文件？

私钥是否保存在普通数据库？

Keystore 是否经过强加密？

解密密码是否也保存在本地？

文件是否受到 iOS Data Protection 保护？

敏感密钥是否依赖 Keychain 或硬件安全能力？

因此，真正决定资产安全的，不只是漏洞本身，还有钱包如何设计本地数据存储。

五、为什么加密钱包尤其危险？

传统互联网应用发生数据泄露，通常意味着账户、隐私或业务信息暴露。

但加密钱包有一个根本区别：

密钥本身就是资产控制权的一部分。

假设一个钱包将助记词以明文形式保存在应用目录中。正常情况下，其他应用无法访问这个目录。但如果沙盒隔离被突破，攻击者就可能读取这份文件。

一旦助记词泄露，攻击者可以在其他设备上恢复钱包。这与是否拿到了原手机、是否知道钱包登录密码，并没有必然关系。

对于其他存储方式，风险则有所不同。

明文私钥：如果能够被读取，资产可能直接面临失控风险。

加密 Keystore：文件泄露不等于密钥泄露，还需要判断加密强度以及解密密码是否同时暴露。

WebView Cookie：可能导致会话信息泄露，但是否能够接管账户，还取决于服务端会话验证和额外认证机制。

Keychain：仍然需要分析具体访问控制属性、密钥可用条件和设备保护机制，不能简单认为放进 Keychain 就绝对安全。

六、版本差异与修复状态：现在应该升级吗？

这是本次事件中最值得关注的信息之一。

目前公开资料中，存在两个不同的受影响版本范围。

Binance 风险提醒：iOS 26.7.1、27.0.1、27.2。

forcequitOS GitHub README：iOS 26.0–26.7.2、27.2。

两者并不完全相同。Binance 列出的是其明确点名的版本，GitHub README 则给出了研究者声明的 PoC 覆盖范围。不能将 Binance 的三个版本理解为完整的受影响版本清单。

修复方面，Apple 于 11 月 9 日发布了 iOS 27.2.1 和 iOS 26.7.3。

但 Apple 官方安全公告没有直接提及 worse_query，也没有明确将这次更新与该沙盒逃逸问题关联起来。

与此同时，SlowMist 安全负责人 23pds 表示，iOS 27.2.1 已经能够阻断 worse_query。

这并不意味着用户应该等待。建议尽快升级到设备能够安装的最新官方 iOS 版本，但在 Apple 或进一步独立验证确认之前，不应将某个版本号视为已经得到官方确认的完整修复结论。

七、用户与钱包团队现在应该做什么？

普通用户：减少攻击入口

1. 删除来源不明的 IPA 和不可信侧载应用。

2. 不要安装所谓的系统解锁、免费增强、钱包辅助工具。

3. 更新 iOS 和钱包应用。

4. 检查钱包是否曾在安装过不可信应用的设备上使用。

5. 如果怀疑助记词或私钥泄露，应在干净设备上创建新钱包并迁移资产，而不是只修改钱包登录密码。

钱包团队：开展针对性安全审查

首先，检查助记词、私钥是否以明文进入 Documents、Library、缓存、日志或普通数据库。

其次，检查 App Group 是否保存了密钥材料、解密凭据或可直接恢复钱包的敏感数据。

然后，检查 Keychain 的访问控制、Data Protection 文件保护等级，以及密钥是否与设备安全能力绑定。

最后，验证交易签名是否能够脱离用户授权独立完成。如果设备端某个密钥材料泄露，是否还存在第二个独立的签名条件？

对于 MPC 钱包，还需要额外检查：

单个设备 Share 泄露是否足以完成签名？

不同 Share 是否真正位于独立的信任域？

是否存在多个 Share 同时保存在同一设备或同一云环境的情况？

是否支持 Share 轮换、设备解绑和异常签名阻断？

这些才是决定一次设备漏洞会不会演变成资产事故的关键问题。

八、从 iOS 沙盒到 MPC：重新思考数字资产的安全边界

worse_query 带来的真正启示，并不是 iOS 不再安全，而是任何单一安全机制都不应该成为资产安全的唯一基础。

操作系统沙盒负责应用隔离，但不应该承担保护完整资产控制权的全部责任。

钱包应用负责密钥管理，但不能假设本地存储永远不会被访问。

硬件安全机制能够提高密钥保护能力，但也不能替代交易授权与风险控制。

这也是 MPC 等多方密钥管理架构的价值所在。

在合理设计的 2-of-3 MPC 架构中，单个设备上的 Share 并不等于完整私钥。即使移动设备遭遇应用层攻击，攻击者取得一个 Share，也不必然能够独立完成签名。

当然，这个前提是其他 Share 确实处于独立的安全域，且签名策略没有被绕过。

进一步看，未来的数字资产安全还需要将密钥控制和交易授权分离：

密钥系统：负责确保谁能够参与签名。

授权系统：负责确保哪些交易可以被执行。

风险系统：负责限制异常金额、异常地址和异常行为。

审计系统：负责记录授权与执行过程。

这对 AI Agent 支付也同样重要。

当 Agent 开始拥有钱包、调用支付接口和执行链上交易的能力时，不能仅仅因为 Agent 拥有某个密钥或 Token，就允许它无限制地支配资金。

结语：真正的安全，是一道防线失效后资产仍然安全

worse_query 从研究型 PoC 发展到 WQ Files 这样的可侧载工具，让我们看到一个值得重视的变化：移动端应用隔离能力并不是永远可靠的。

对于普通用户，最直接的教训是：不要随意安装来源不明的 IPA。

对于钱包开发者，最重要的教训是：不要把密钥安全寄托在操作系统沙盒之上。

对于金融基础设施建设者，则需要进一步思考：

如果某台设备已经失陷，攻击者是否能够直接取得资金控制权？

如果某个密钥分片已经泄露，整个签名体系是否仍然安全？

如果某个 Agent 已经被攻破，它是否仍然只能在用户预先授权的范围内执行交易？

这才是从移动应用安全走向下一代金融基础设施安全，需要完成的转变。