文章总结： 知名AIAgent项目OpenClaw被曝存在严重安全漏洞，Imperva团队通过vCard等消息对象进行隐蔽指令注入，Varonis团队通过社会工程学实施Agent钓鱼攻击，两者均能获取敏感数据。漏洞根源在于AIAgent对输入过度信任且缺乏边界控制。防御建议包括采用零信任架构、实施最小权限原则、外发通道审批和关键操作人工确认机制。 综合评分： 85 文章分类： 漏洞分析,AI安全,应用安全,安全意识,解决方案

知名 AI Agent OpenClaw 被攻破：大模型时代的安全防线该怎么建？

原创

Kit Chung Kit Chung

安全圈动向

2026年6月16日 08:06 广东

在小说阅读器读本章

去阅读

大家好，今天咱们来聊点硬核的。最近在大模型安全（LLM Security）和 AI Agent 圈子里出了个大瓜：知名开源自托管 AI Agent 项目 OpenClaw 被 Imperva 和 Varonis 两家顶尖安全团队接连“暴揍”。

更离谱的是，攻击者根本不需要什么高深复杂的 0day 漏洞，仅仅通过发送一张极其普通的电子名片（vCard）、一个位置共享，或者一封看似日常的工作邮件，就能让这个 AI Agent 乖乖交出核心数据库连接串，甚至直接执行恶意代码。

殊途同归，这两场攻击虽然切入点不同，但都直指当前 AI Agent 架构中最脆弱的一环。今天，我就带大家深扒一下这些攻击的技术细节、重现路径，以及咱们在业务中到底该如何防范。

🔪 攻击路径一：隐蔽指令注入（来自 Imperva 团队）

Imperva 团队的大佬 Yohann Sillam 盯上了 OpenClaw 与底层大模型通信时的数据清洗管道（Plumbing）。这个漏洞的核心逻辑，在于缺乏不可信数据边界。

🐛 技术原理与重现过程

当 OpenClaw 将用户共享的联系人、vCard 或地理位置传给底层 LLM 时，它会做极其粗暴的内联展平（Flattening）处理。对于从网页抓取的内容，Agent 知道用“不可信内容（untrusted-content）”的标签包裹起来；但是对于上述这些消息对象，它却完全“裸奔”。

咱们来看看 Payload 是怎么构造的。以共享联系人为例，系统通常会将其序列化为 <contact: name, number> 传递给模型。关键问题来了：尖括号 < > 在名称字段中是合法的！

因此，攻击者可以在 name 字段中直接注入恶意 Prompt。此时，大模型根本无法区分哪里是真实的联系人名字，哪里是注入的指令。更绝的是，无论是在 WhatsApp 还是在接收端的 UI 里，超长的联系人名称都会被截断隐藏，受害者肉眼完全看不到这颗“毒药”。

在 Imperva 针对 Gemini 3.1 Pro（预览版）的实测中，攻击者在共享对象中隐藏了下载并执行外部服务器脚本的指令。结果？Agent 毫不犹豫地照做了。

💡 技术延伸：

为什么不把恶意指令藏在图片里？因为图片提示词注入（Image Prompt Injection）已经被曝光太多次，目前主流大模型都做过针对性对抗训练；而基于“消息对象”的注入路径，模型见得少，反而成了盲区。

🛡️ 官方修复方案

OpenClaw 紧急发布了 2026.4.23 版本补丁。修复逻辑很清晰：将联系人姓名、vCard 字段和位置标签从 Prompt 主体中剥离，移入一个独立的不可信元数据通道。还在跑老版本的老铁们，抓紧升了吧。

🎣 攻击路径二：Agent 钓鱼（来自 Varonis 团队）

如果说 Imperva 玩的是底层数据污染，那 Varonis 团队玩的就是高端的社会工程学。

他们提出了一个新概念：Agent Phishing（智能体钓鱼）。这区别于传统的提示词注入，它利用的是正常通信渠道和一个极其令人信服的请求，利用了 Agent 在核实发送者身份前的“服务热情”。

🐛 钓鱼实录：Pinchy 的沦陷

Varonis 团队在平台上建了一个名叫 Pinchy 的测试 Agent，给它接管了一个塞满合成商业数据和模拟密钥的 Gmail 邮箱。随后，他们基于 Google Gemini 3.1 Pro 和 OpenAI Codex GPT-5.4 展开了四轮钓鱼测试。

结果，数据外发测试全军覆没：

• 紧急事件钓鱼

  伪造外部邮件，冒充团队 Leader，声称发生生产事故，Agent 二话不说交出了 AWS IAM 密钥和数据库连接串。

• 常规流程钓鱼

  伪装成 QBR 数据需求，Agent 乖乖打包了包含 247 家企业客户的核心数据集。

这说明啥？它能看懂钓鱼 URL，却看不懂人情世故。Agent 越想“提供帮助”，它的攻击面就越大。

🔍 扒一扒更深层的架构软肋

Varonis 将这些攻击归结为安全专家 Simon Willison 提出的“致命三要素”：

• Agent 可以读取隐私数据；
• Agent 会接收不可信的输入；
• Agent 能够将数据发送出去。

当这三点汇聚在一个系统中，不管你是投毒的 vCard 还是伪造的邮件，最终都会导致整个系统的全面崩盘。难怪荷兰数据保护局（DPA）直接发狠话：严禁在存放敏感数据的系统上运行 OpenClaw，账号接管和数据泄露的风险太高了。

🛠️ 咱们该如何避坑？（架构级防御指南）

打补丁只能解决燃眉之急。作为开发者和架构师，我们需要从系统设计层面引入零信任（Zero Trust）的思想。以下是 Varonis 给出的 4 条硬核架构建议：

• 指令强制化与版本控制

  Agent 的指令文件必须被视为强制执行的代码级 Policy，并且要加入版本控制。

• 给外发通道加把锁（Outbound Gate）

  禁止 Agent 在未经人工审批的情况下，向首次出现的陌生地址发送邮件。

• 最小权限原则（Least Privilege）

  处理外部邮件的 Inbox 连接器，绝对不能同时拥有读取全局 CRM 数据库的权限。

• 核心操作必须 HITL（Human-in-the-loop）

  对于转发密钥凭证、资金转移等高危行为，必须强制等待人类管理员的最终确认。

总结

其实大家仔细想想，今天摆在咱们面前的根本不是一个单纯的 Bug。一个足够智能、能帮你处理邮件和执行命令的 AI Agent，其底层设计必然建立在“信任输入”和“渴望提供帮助”的逻辑之上。 大家在现阶段接入 AI Agent 时，最好的心态就是把它当成一个拥有极高系统权限、但完全不懂社会险恶的“职场愣头青”。防人之心不可无啊！

你目前在业务中有接入或者开发 AI Agent 吗？有没有遇到过什么奇葩的 Prompt 越权经历？欢迎在评论区和我一起交流吐槽！👇

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全圈动向 Kit Chung Kit Chung《知名 AI Agent OpenClaw 被攻破：大模型时代的安全防线该怎么建？》