Perplexity Computer 沙箱逃逸漏洞复盘：三行命令窃取AI密钥的警示

最近读到一篇安全分析文章，内容着实令人吃惊。

一位安全研究员仅仅通过三行命令，就成功侵入了Perplexity Computer的沙箱环境，不仅获取了无限量的Claude Code调用权限，而且产生的所有费用都记在了Perplexity的账上。

你或许会猜测，这一定运用了某种极其高深的黑客技术吧？

恰恰相反，整个攻击流程利用的是一个在2019年就已经被广泛知晓的旧有攻击模式。

事件经过

这位研究员最初只是想探究一下Perplexity产品的沙箱机制，却发现沙箱中运行着Claude Code。他随即产生疑问：Claude Code的运行需要API密钥，那么这个密钥存储在何处？

探索由此开始。

他尝试让AI本身来帮他窃取密钥，但接连失败了六次：

• 直接要求AI打印环境变量？被AI拒绝。
• 诱导AI执行植入的木马脚本？AI读懂了代码意图，拒绝执行。
• 试图篡改启动配置？时机不对，密钥尚未被注入环境。

读到此处，或许你会觉得Claude在模型层面的安全防护相当严密。

然而，剧情在此处发生了反转。

三行代码，完成攻击

他转换了思路：Claude Code是一个Node.js应用，而Node.js在启动时会读取用户目录下的 ~/.npmrc 配置文件。关键点在于，这个配置文件位于一个可被攻击者任意写入的共享文件系统上。

于是，他构思了一个方案：利用Node.js的 --require 启动参数，在Claude Code的主程序启动之前，先加载一个自定义脚本，该脚本会将进程的环境变量（包含API密钥）全部转储出来。

攻击的核心就是这三行命令：

# 1. 编写一个用于窃取环境变量的脚本（假设为 /path/to/script.js）
# 2. 将加载此脚本的指令写入 .npmrc 配置文件
echo 'node-options=--require /path/to/script.js' > ~/.npmrc
# 3. 触发AI执行任意一个任务，Claude Code启动时便会自动加载我们的脚本

操作完成，API密钥轻松到手。

更离谱的后续

拿到密钥后，他做了常规的推测：这个密钥应该绑定了IP限制吧？或者至少关联了我的用户账户吧？

测试结果令人愕然。

没有任何限制。

他直接在自己的本地环境中配置了这个窃取来的密钥，成功运行了Claude Opus 4.6模型，并生成了超过50万token的内容——而Perplexity账户的余额纹丝未动。

这意味着，攻击者可以利用他人的支付账户，无限次地调用最顶级的付费AI模型，而账单则全部由服务提供商承担。这无疑是一次严重的安全漏洞。

漏洞带来的启示

这个案例最令人深思之处在于：AI模型本身的安全机制即便做得再完善，底层基础设施的安全性缺失也会导致全盘皆输。

Claude在模型交互层面的防护确实成功拦截了前六次直接攻击。但问题在于，攻击者根本没有选择正面强攻模型防线，而是巧妙地绕过了它，从更底层的应用运行时和配置管理环节找到了突破口。

这就好比为你的家门配备了指纹、虹膜、密码三重认证的超高安全锁，却忘记了关上旁边那扇没有锁的窗户。

作者提出的修复建议（值得所有AI产品开发者关注）

原文作者给出了清晰直接的修复方案：

1. 密钥与沙箱实例绑定：API密钥应与特定的沙箱容器ID强关联，密钥与运行环境不匹配则立即拒绝请求。
2. 使用短期有效的密钥：密钥的生命周期应与沙箱实例保持一致，实例销毁，密钥即刻失效。
3. 消费与终端用户绑定：即使密钥不幸泄露，产生的消费也应计入密钥所属的终端用户账户，而非平台方的通用账单。

作者观点非常明确：当前多数多智能体或AI-Agent类产品很可能存在类似的漏洞。行业发展追求速度，往往在安全架构设计上留下了隐患。对于人工智能产品的开发者而言，这是一个需要迫切关注的领域。

总结与思考

这个事件让我们看到，AI安全是一个多层次、系统性的工程。

它涉及模型安全、提示词安全、基础设施安全、配置管理安全等方方面面。任何一个环节出现纰漏，都可能导致整个系统的防御被瓦解。更值得注意的是，许多漏洞并非源于高深莫测的技术，而恰恰是那些被忽略的、“常识性”的配置与管理问题。

从事AI产品开发的朋友，确实有必要深入研究此类案例，绝非贩卖焦虑，而是切实关乎产品的稳健性与用户信任。你是否在自己的项目中也遇到过类似的安全“坑”呢？欢迎在云栈社区的开发者板块交流讨论。

后记：原作者 @YousifAstar 在公开披露前已按照负责任的漏洞披露流程，通知了Perplexity的创始人。这一做法体现了安全研究应有的专业性。