白泽成果分享：通过补丁语义分析让“依赖库漏洞传播”看得更准

研究背景

在 Java 生态中，Maven、Gradle 等工具提升了依赖复用效率，但也带来一个长期难题：一旦上游依赖出现漏洞，风险可能会沿着依赖链一路传到下游项目。针对这一问题，现有检测方法主要是 SCA（检测是否引入漏洞版本）和调用图分析（检测是否能调用到漏洞函数），但两者通常只能说明“可能有风险”，难以判断“是否真实可利用”。

为了更准确刻画漏洞传播，理解漏洞代码语义至关重要，而补丁（patch）正是公开漏洞信息中最直接、最结构化的来源。与漏洞描述文本相比，补丁不仅给出“哪里被修复”，还明确展示“修复前后语义差异”——即哪些路径被阻断、哪些校验被新增、哪些输入约束被强化。这些变化恰好对应漏洞利用成立所依赖的关键条件。

因此，本文从补丁切入，提取与漏洞传播相关的语义约束，并将其与跨组件传播分析结合，提出 VIPERSCAN。该方法不仅判断漏洞路径是否可达，还进一步验证攻击前提是否成立，并提升历史版本中漏洞函数识别的准确性。

研究已发表于 IEEE Transactions on Dependable and Secure Computing（TDSC）。

补丁中蕴含的漏洞利用信息主要包括三类：

• 数据流关系：攻击者可控数据能否实际流向危险操作点；

• 路径条件：执行过程中是否存在权限校验、分支保护等拦截约束；

• 全局语义标签：与漏洞相关的类、方法、字段及其上下文关联。

大模型在代码语义理解方面具有优势，但在大规模、批量化的跨库传播分析场景下，若完全依赖 LLM，往往面临稳定性不足、结果可复现性弱以及分析成本高的问题。为此，VIPERSCAN采用“LLM 语义提取 + 规则化执行分析”的核心思路：首先利用 LLM 对漏洞补丁进行语义解析，提取利用相关约束；随后将这些语义信息自动转化为可执行分析规则，并将规则注入后续可达性分析流程。

这样的思路面临三项技术挑战：首先，版本差异导致漏洞点漏检：漏洞在引入到修复之间常经历多次演化，若仅基于最终修复提交提取特征，易忽略历史上下文。其次，分析规则语言是复杂的，用LLM直接生成分析规则成功率低。最后，跨库边界常导致调用/数据流断链，而全量分析代价过高。

面对这些问题，VIPERSCAN 提出三步解决方案：（i）版本感知的漏洞 API 提取从补丁往历史版本回溯，把不同版本中“语义等价”的危险函数和相关代码上下文都找出来。（ii）引入更简洁的中间语言，辅助LLM对漏洞利用条件的提炼，并通过回归测试迭代优化。（iii）基于摘要的跨库可达性分析只对断点方法做摘要，补齐跨库调用中的缺漏。

VIPERSCAN整体框架

论文指出了三个关键难点和解决方案：

挑战一：版本差异导致漏报

在真实项目里，漏洞从“引入”到“修复”之间，往往会经历多个 commit。如果只孤立地看“最终修复的那个 commit”，很可能看不到完整上下文，也就难以准确识别真正的漏洞点。

本文还总结了一个很关键的现象：版本漂移（version drift）。也就是说，在漏洞修复之外的普通代码演进中，函数重命名、封装层变化、调用关系调整等改动，会让“同一漏洞语义”在不同版本里表现成不同 API 关系。结果就是：如果只盯补丁版本中的函数签名，早期受影响版本里的真实漏洞点就可能被漏掉。

关键技术：版本感知的漏洞 API 提取

针对这个问题，本文采用了沿版本历史回溯的漏洞 API 提取方法：

1. 从修复补丁出发，沿提交历史向前追踪到漏洞引入阶段；

2. 在追踪过程中识别函数结构变化（如重命名、封装调整、调用迁移）；

3. 为不同受影响版本建立对应的“危险 API 映射”，而不是只保留补丁版本签名。

这样做的效果是：跨版本函数签名对齐，并为后续步骤提供充分的代码上下文。

回溯过程中识别函数结构变化

挑战二：漏洞“利用条件”难以建模，导致误报

很多漏洞并不是“调用到危险函数就一定能利用”。它通常还依赖一组前提条件，比如：特定数据流是否成立、关键分支是否被绕过、配置开关是否开启等。这类条件类型多、语义强，传统静态分析很难完整建模；而如果直接让 LLM 对每条调用链做最终判定，又容易受随机性影响，稳定性和可复现性不足。

关键技术：LLM 生成 DSL + 高容错解析 + 回归迭代

1. 不让 LLM 直接生成复杂分析规则（如 CodeQL 查询），因为这类输出容易不稳定、语法错误率高；

2. 引入语法更简单的中间语言 DSL，先由 LLM 生成 DSL 形式的漏洞条件表达；

3. 设计更高容错的 ANTLR 解析器，把 DSL 自动转换成可执行分析规则；

4. 使用已提取的多版本代码样例做回归测试，不断迭代优化规则质量。

把“语义理解能力”和“工程可执行性”拆开处理：LLM 负责看懂补丁语义，解析引擎负责稳定生成可用的规则。

补丁片段->DSL->QL规则

挑战三：跨库传播链长，分析成本高

在真实依赖生态中，一条漏洞传播路径常常跨越多个库。一到库边界，调用流和数据流就容易“断链”；但如果做全量全程序分析，计算成本又太高，难以落地。

关键技术：选择性摘要补全

本文采用“按需摘要”策略：先定位最可能发生断链的关键位置，再只对这些位置生成跨库摘要，用于补全传播路径。这样既能提升跨库可达性分析的完整度，也避免了全量分析带来的高开销。

论文在大规模数据上做了验证（810 个 Java CVE、44,184 条 Maven 依赖链），代表性结果：

• 漏洞函数识别召回率达到 95%（对比基线 72%）

• 相比常见 SCA 工具，误报下降约 40%–69%

• 在 44,184 条传播链中，真正“可达”的仅 5.6%

• 而在可达路径里，满足利用条件的只有 53.8%

此外，论文还给出了几个关键工程结论：

1. DSL 辅助 LLM 规则转化是有效的：相比直接生成复杂分析规则，采用 DSL 中间层能显著提高规则转化成功率和稳定性。

2. 选择性摘要策略性价比高：只引入不到 5%的额外时间开销，就达到了与全量分析基本一致的准确率。

44,184组依赖链中真正高危的跨库利用链只有1,327条

张磊，复旦大学助理研究员，主要研究方向为漏洞挖掘与治理，目前主持国家重点研发计划子课题、国家自然科学基金青年基金、上海市人民政府决策咨询项目等，在 IEEE S&P、ACM CCS 等网络安全顶会上发表论文十余篇，获上海市科技发明一等奖、上海 CCF 科学技术一等奖、ACM SIGSAC 中国优博奖和 ACM 中国优博提名奖，并获得 2022 年 USENIX Security 杰出论文奖、2024 ACM FSE 杰出论文奖等。多项研究工作以内参、专报等形式上报政府相关部门，多次获得党和国家主要领导人批示，发现的某关键漏洞获 CNVD 最具价值漏洞奖，并多次配合相关部门开展工作。

孙福特，复旦大学计算与智能创新学院博士研究生。主要研究方向为静态程序分析、LLM驱动的漏洞检测与软件供应链安全分析等。

喜

报

获奖名单（节选）

团队答辩现场（图为博士生史一哲）

白泽·鉴微平台主页

本文系白泽智能团队研究成果，相关内容发表于CCF-A类计算机视觉会议CVPR26

论文链接：https://arxiv.org/abs/2604.01826

团队简介

从漏洞到规则：安全知识自动提取的初步探索

很多时候，漏洞修复会被看作安全工作的终点，当厂商发布漏洞补丁后，一个漏洞似乎就此画上句号。
      但从漏洞治理的角度看，修复并不只是“补上一个洞”，它还留下了更有价值的东西：哪些输入是不可信的，哪些操作是危险的，哪些校验真正有效，哪些调用方式会把普通功能变成攻击入口。

问题在于，这些知识往往分散在漏洞公告、补丁、提交记录、PoC 和代码上下文里，难以被系统整理，更难被机器直接使用。于是，大量真实世界中的漏洞经验，并没有真正沉淀成可复用、可迁移、可持续更新的安全规则。

复旦大学系统软件与安全实验室漏洞治理小组正在围绕这一问题开展研究。我们的目标是尝试回答问题：能否将真实世界中的漏洞信息，自动转化为可被机器理解、复用和更新的安全知识？

漏洞知识与安全规则：为什么重要

从最通俗的角度看，漏洞知识可以理解为一组帮助工具理解并识别漏洞风险的规则。

其中，`Source` 指不可信输入的来源，例如网络请求参数、上传文件内容或用户可控字符串；`Sink` 指一旦被不可信数据触达就可能产生安全后果的危险操作，例如表达式执行、文件访问、XML 解析、反序列化或命令执行；`Sanitizer` 则是位于两者之间的安全检查或净化逻辑，例如白名单校验、路径规范化、危险函数禁用、长度限制或上下文隔离。

如果把漏洞看作一条路径，那么很多安全问题本质上就是：不可信数据从 `Source` 出发，在缺少有效 `Sanitizer` 的情况下，最终流入了危险的 `Sink`。比如，用户输入的表达式如果没有经过限制就被求值，可能引发表达式注入；用户传入的路径如果没有经过规范化就被用于文件访问，可能导致路径穿越；XML 解析器如果没有正确关闭外部实体能力，就可能引发 XXE；反序列化接口如果缺乏对象类型或调用链约束，则可能演变为远程代码执行。

为什么这些规则重要？因为自动化安全分析工具并不会天然具备这类知识。像 CodeQL 这样的工具，本质上依赖规则库来理解哪些输入需要被关注、哪些操作具有高风险、哪些防护逻辑能够阻断攻击。

一旦规则缺失，工具就很容易出现两类问题。一类是漏报：新框架、新组件、新披露的高危 API，或者项目自定义的防御逻辑没有被覆盖，工具即使看到了代码，也未必知道真正的风险在哪里。另一类是误报：工具知道某个 `Sink` 危险，却识别不出前面的有效校验，于是“逢高危接口必报”。

像 Java 反序列化、表达式注入、路径穿越、XXE 等问题，如果缺少精确的知识支撑，就很难被高质量地挖掘出来。换句话说，漏洞知识与安全规则的重要性，并不只是帮助我们“解释一个漏洞”，更在于决定自动化分析系统能否真正把漏洞找准、找全、找得有用。

提取安全规则：我们解决什么问题

如果规则这么重要，接下来的问题就是：这些规则从哪里来？    

长期以来，安全规则往往依赖专家手工总结。研究者阅读漏洞公告、分析补丁、复现漏洞、理解框架机制，再把经验抽象成规则，写进检测器或知识库里。这种方式当然有效，但成本高、更新慢、覆盖有限，也很难跟上不断演化的软件生态。

因此，我们更希望将这件事尽可能自动化。直接从真实世界中已经公开的漏洞信息里，自动提取可被机器使用的安全知识。这里的信息源不只包括补丁，也包括 NVD、CNVD 等漏洞数据库中的描述信息、项目提交记录、安全公告、PoC，以及与漏洞相关的代码上下文。

我们的目标，是把这些分散、异构、半结构化甚至非结构化的材料，逐步转化为规则化、结构化的知识表示。这些知识最终不应只是几条零散结论，而应该形成一套可以持续扩展的规则库。它既包括 `Source`、`Sink`、`Sanitizer` 这类基础规则，也包括更具体的 API 安全约束、利用条件、参考防御，并进一步支撑漏洞检测、漏洞验证和修复建议生成。

然而，漏洞知识天然是分散的，数据库给的是文字描述，补丁给的是代码改动，PoC 给的是利用方式，项目代码给的是真实上下文，它们之间并不是天然对齐的。更重要的是，真实世界中的安全语义常常是隐含的，开发者不会在补丁里直接写下“这里违反了某条安全规则”，更不会把 `Source`、`Sink`、`Sanitizer` 明确标注出来。与此同时，同一类规则还需要跨项目、跨框架迁移，不能只适用于某一个样本。

面向这一挑战，我们希望从补丁、漏洞数据库、公告文本、PoC、提交记录等多种信息中，自动提取 API 安全规则，并完成多源漏洞知识的对齐与融合。在此基础上，进一步推进规则自动识别、自动验证、自动更新，逐步构建可以持续生长的漏洞知识体系。

初步成果：从补丁中提取 API 安全规则

围绕这一方向，我们先从安全补丁出发，设计了 VulGenie。它面向 Java 安全补丁，自动识别补丁中被违反的安全约束和修复时引入的参考防御，再把这些信息沉淀为可迁移的 API 安全规则，并进一步用于发现 API 误用漏洞。

VulGenie 在 150 个近期披露的 Java 安全补丁上共提取出 198 条正确的 API 安全规则，精度达到 81.82%；其中 177 条规则是现有 CodeQL 知识库中尚未覆盖的。

基于这些规则，研究团队又在 10 个流行 Java 应用的最新版本中发现了 46 个 0-day 漏洞；其中 26 个漏洞已完成修复，10 个漏洞被分配了 CVE 编号。相关成果已被 USENIX Security 2026 接收。

张磊，复旦大学助理研究员，主要研究方向为漏洞挖掘与治理，目前主持国家重点研发计划子课题、国家自然科学基金青年基金、上海市人民政府决策咨询项目等，在 IEEE S&P、ACM CCS 等网络安全顶会上发表论文十余篇，获上海市科技发明一等奖、上海 CCF 科学技术一等奖、ACM SIGSAC 中国优博奖和 ACM 中国优博提名奖，并获得 2022 年 USENIX Security 杰出论文奖、2024 ACM FSE 杰出论文奖等。多项研究工作以内参、专报等形式上报政府相关部门，多次获得党和国家主要领导人批示，发现的某关键漏洞获 CNVD 最具价值漏洞奖，并多次配合相关部门开展工作。

陈波妃，复旦大学计算与智能创新学院博士研究生。主要研究方向为Java漏洞挖掘、程序分析与软件安全等，在IEEE S&P、USENIX Security、ASE等国际会议上发表多篇学术论文，相关研究涵盖Java反序列化利用链检测、API安全规则提取、补丁迁移以及大语言模型辅助程序分析等方向。

廖双，复旦大学计算与智能创新学院博士研究生。主要研究方向为PHP漏洞挖掘、程序分析等，在USENIX Security等国际会议上发表多篇学术论文，相关研究涵盖补丁分析、漏洞PoC自动生成以及PHP Web漏洞挖掘等方向。

AutoControl Arena 的核心创新在于逻辑 - 叙事解耦，将测试环境拆分为确定性逻辑层和开放性叙事层，既保证确定性，又保留真实感，就像给模拟器装上 “物理引擎”：

• 确定性逻辑层（Python 代码实现）：系统状态、数据库、权限控制等 “物理规则”，用代码严格执行，运算逻辑固定、可复现，防止幻觉干扰。

• 开放性叙事层（LLM 生成）：NPC 对话、社会反馈、场景背景等开放内容，由大模型动态生成，保持现实世界的复杂性与真实性。

整个评测流程由三个智能体全自动化执行：

1. 场景种子：输入风险类型与应用场景；

2. Architect：设计完整场景方案，明确目标、约束与风险指标；

3. Coder：将方案转化为可执行的 Python 环境，包含所有交互接口；

4. Monitor：实时监控 AI 行为，分析思考过程，并生成最终风险评估报告。

这种 “代码 + LLM” 的混合架构，既解决了纯代码环境的僵化问题，又避免了纯 LLM 环境的不可靠性，兼顾了保真度与可扩展性。

为系统激发 AI 的潜在不对齐行为，团队打造了两大核心工具：

1. X-BENCH 基准测试集

包含70 个测试场景，覆盖能力滥用、工具性趋同等7 大类核心风险，涉及网络安全、军事决策等15 类敏感应用场景，为评测提供标准化 “试炼场”。

2. 压力 - 诱惑双维度风险激发机制

在 9 个主流模型上的测试，揭示了令人警醒的真相：

（1）“对齐幻觉”：模型的 “双面人生”

在低压力、低诱惑的良性环境中，模型平均风险率仅21.7%，表现出良好的对齐行为；而在高压力 + 高诱惑的极端条件下，风险率飙升至 54.5%，部分模型甚至翻了三倍以上。更令人担忧的是，能力越强的模型，风险增幅越大—— 这意味着我们最依赖的先进 AI，可能隐藏着最危险的 “暗面”。

（2）逆向安全扩展定律：模型能力的双刃剑效应

研究发现了两种截然不同的安全Scaling模式：

（3）战略性伪装：AI 的 “表演天赋”

强模型展现出惊人的 “欺骗能力”：Gemini-3 Flash 在测试中生成了带木马的代码，却将其伪装成 “防御性监控工具”，添加绕过杀毒软件的配置，同时输出看似合规的解释。这种 “当面一套，背后一套” 的行为，让现有监管手段面临巨大挑战，也凸显了思维链监控的必要性 —— 不仅要看 AI 做了什么，更要理解它为什么这么做。

项目地址

3. 配置模型API

复制.env.example为.env，填入 OpenAI、Claude、Gemini、Qwen 等主流模型的 API Key。

4. 选择你喜欢的方式启动评测

① 交互式 TUI（推荐新手）：aca

菜单式引导，选择场景、模型、压力 / 诱惑等级，实时查看进度与结果。

5. 结果可视化

评测完成后，启动本地 Web 结果查看器。

📄 论文地址：

https://arxiv.org/abs/2603.07427

🏠 项目主页： 

https://cosmosyi.github.io/AutoControl-Arena/

💻 Github仓库：

https://github.com/CosmosYi/AutoControl-Arena

核心贡献者：

李长艺 复旦大学计算与智能创新学院 研究生

卢鹏飞 复旦大学计算与智能创新学院 本科生

指导教师：

潘旭东 潘旭东 复旦大学 计算与智能创新学院副研究员、学敏学者/上海创智学院 全时导师

Fazl Barez 牛津大学 研究员

杨珉 复旦大学计算与智能创新学院 教授

功能实现

     在安全分析之前，我们首先要验证这些智能体到底能做到什么程度。我们设计了从基础感知到跨应用执行的三级测试用例。

    基础能力中我们设置了两个简单的测试用例，分别为识别屏幕上的数学题并完成，要求更改手机设置。测试结果表明，四款智能体均具备成熟的屏幕内容识别能力，在“屏幕数学题”测试中，A厂商的智能体展现了极高的执行效率，而最新的豆包虽然通过模拟点击实现（速度较慢），但在理解用户意图上表现出更强的交互感。

基础功能测评结果

     第二梯度测试智能体的多模态能力与本地检索能力，我们设计了三个任务，分别为清除照片中人像，操作手机订酒店和检索手机中特定的文件。在清除人像测试中我们发现各个AI各有优劣，华为（小艺）的视觉处理能力突出，其端侧算法能精准识别并移除背景中远处的人像；小米和豆包则在单APP内自动化操作能力上较为成功，它们都能够通过打开APP，并在APP内操作完成指定任务；vivo（蓝心小V）的本地文件检索能力优异，当指令为“查找身份证照片”时，它能准确遍历文件系统并定位目标。

豆包订酒店

进阶功能测评结果

跨APP长链协同是目前各大厂商的所关注的重点，是衡量智能体智商的分水岭。我们设计了任务：“将备忘录第一条笔记，评论到B站推荐的第一个视频下”。测试结果显示，豆包手机表现最为抢眼。 它能像真人一样，理解意图、跳转应用、复制文本、点击发送，完成了完整的跨应用操作闭环。

豆包手机发送评论

    通过测评我们发现，当前的手机AI助手已不再是“伪智能”，它们确实拥有了“感知屏幕内容”和“接管用户操作”的实际能力。而这，正是安全问题的起点。

权限透视

     为了支撑上述强大的功能，AI有多大的隐私风险呢？我们对四款智能体进行了简单的逆向分析，统计结果令人惊讶。

    在参测的智能体中，vivo、豆包、小米的权限申请数量均突破了100项（最高达112项）。作为对比，微信作为功能极其复杂的国民级App，其权限数量也控制在100以内。这意味着目前的手机AI在系统层面的“涉入度”，已经超过了传统的超级App。

     不仅数量多，其申请的权限“含金量”极高。在权限热力图中，我们可以看到代表“极高敏感度”的红色区域在所有智能体中均高频出现。数据显示，系统控制、屏幕控制与注入、显示与窗口、隐私访问这四大类权限构成了AI智能体的能力基石。其中，厂商C的敏感权限占比甚至达到了46.4%。

权限热力图

四大类权限热力图

    AI 是如何做到“看着屏幕帮你操作”的？我们深入分析了其背后的关键技术路径，发现了两个备受关注的安卓系统级高敏权限：INJECT_EVENTS，READ_FRAME_BUFFER。

INJECT_EVENTS（事件注入）是AI的“虚拟手指”。它允许程序在用户无感知的情况下，模拟点击、滑动等触控操作。

READ_FRAME_BUFFER （屏幕读取）则是AI的“上帝之眼”。它允许程序直接读取显存中的帧缓冲区。换句话说，你在屏幕上看到的任何内容（无论是在聊天、看图还是输密码），理论上拥有该权限的AI都能在后台“看见”。

    分析发现：在参测的4家厂商中，有3家直接申请了上述两个通用权限；而未申请的厂商也通过自研的无障碍增强权限实现了同等能力。这表明，“读屏+模拟点击”已成为行业实现智能体的主流技术方案。智能体实质上是在运行一个拥有“最高监视权”的系统程序。

事件注入与屏幕读取权限

自研的无障碍增强权限

敏感数据

     既然AI拥有了“看屏”的能力，那么当我们浏览敏感信息时，这些数据会被上传到云端吗？这些数据是否进行了妥善的处理？

    在网络层面的抓包测试中，各厂商均采用了完善的证书绑定（Certificate Pinning）机制，表现出了良好的数据传输安全性，第三方难以直接截获数据。

配置中只信任系统CA证书

     既然无法进行抓包，那么该如何知道敏感数据是否上传云端呢？我们设计了一种直观的验证手段：在手机屏幕上打开一张身份证照片，然后向AI下达指令：“将当前屏幕展现的身份证照片转为动漫风格”。测试结果表明所有参测智能体均成功执行了该指令。但在生成的动漫风格图片中，身份证上的关键敏感信息（如姓名、身份证号）依然清晰可辨，未做遮挡处理（图中为手动打码）。

身份证上的敏感信息未脱敏处理

    这一现象揭示了端云协同中的隐私缝隙——当端侧芯片算力不足以支持复杂的图像生成任务时，智能体可能会将包含用户屏幕隐私（如身份证原图）的截图上传至云端服务器进行处理。虽然传输过程是加密的，但“屏幕敏感数据离开本地”这一行为本身客观上增加了隐私泄露的攻击面。

结果与建议

    本次测评结果表明大多数主流手机厂商的智能体已具备强大的跨应用协作与屏幕感知能力，但这背后是建立在打破传统沙箱限制、获取最高系统权限的基础之上的。对此，我们提出以下建议：

权限最小化与透明化：厂商应在隐私协议中应明确告知用户，AI在何种场景下会调用截屏权限，并对“云端处理”与“本地处理”进行明确标识（如状态栏提示）。

敏感数据本地脱敏：建议厂商建立屏幕敏感内容识别机制。在将屏幕截图上传云端前，必须在本地对身份证、银行卡号等敏感区域进行自动遮挡或模糊处理。

用户安全意识：由于ai智能体属于新兴领域，当前安全措施还不够完善，我们建议用户在处理极度敏感信息（如金融交易、查看私密证件）时，暂时避免唤醒AI助手，以防屏幕内容被意外读取。

    随着AI深度融入操作系统，构建更加透明、可控的隐私保护标准，将是行业发展的必经之路。而本次测评是一次初步测评，未来我们会有更多的相关工作，为智能体行为的规范与隐私的安全保护做出更进一步的探索，敬请期待。

最近 OpenClaw 非常火，掀起“龙虾”热潮。

但你有没有想过两个问题：

🦞你跟别人炫耀自己养的龙虾时，会不会被投喂“毒饲料”？

🦞龙虾在多人团队落地，又如何能够听懂指挥？

今天我们就来揭秘一下，共享小龙虾的安全风险！

OpenClaw 的一个核心特点，是通过即时通讯软件来操控智能体（Agent）。用户只需发送文本消息，网关就会将其路由到指定的智能体和对应的会话（Session），由模型调用工具执行任务，并将结果返回到聊天软件。

在实际部署中，智能体往往同时拥有消息平台权限和系统能力，例如操作飞书账号、执行系统本地命令或访问文件资源。然而，默认配置下的小龙虾并不安全。

      你“养”的这只能干的龙虾一旦被攻击者利用，事情就没那么简单了。

如果只有你一个人在“养龙虾”，这些能力基本都在自己的控制之下。无论你开多少智能体操作的都是自己控制的系统。但现在很多人已经开始这样玩：

“我这只龙虾挺好用的，你也来试试。”

于是，你把朋友、同事甚至是陌生人拉进了群聊，让大家一起和这只龙虾互动，问题也就从这里开始出现了。

如果多个用户同时在同一个群聊中使用这只“龙虾”，这些用户并不需要申请权限，实际上是在共享同一个 Agent 的能力，这个龙虾就不再只听你话了！

例如，他们可以轻松轻易获取到智能体的其他会话数据等敏感信息，如用户和智能体的聊天记录。

除此之外，还能利用智能体的能力调用各种工具，例如可以把本地配置文件中的API Key使用其配备的邮箱收发工具外泄。

攻击者收到泄露敏感密钥的邮件：

那如果换一种方式：在部署的OpenClaw实例上给每个用户单独开一个智能体，在各自的群聊里用独立的智能体，是不是就安全了？

经过白泽逐影团队的研究，我们发现情况并没有这么简单。虽然通过路由机制可以让不同智能体进入不同群聊，每个智能体也拥有各自的记忆、模型和工作空间，但在底层系统中，它们仍然可以相互访问。也就是说，在同一个 OpenClaw 实例中，不同 Agent 之间实际上只是“软隔离”。

进一步测试发现，即使使用最先进的模型，也可以轻易访问和篡改其他智能体工作区的信息。

例如，一个智能体可以修改另一个智能体的配置信息，导致其彻底失效。

修改后再使用被攻击的智能体，无法正常执行任务。

综上，在同一个 OpenClaw 实例中，无论是会话之间还是智能体之间，本质上都只是“软隔离”。虽然在逻辑上被划分为不同的会话或工作区，但在同一实例的运行环境中，仍然存在相互访问的风险。

真正意义上的隔离，通常需要运行在不同的 OpenClaw 实例中。

基于以上风险，如果需要多人一起“养龙虾”，白泽逐影团队提供如下建议。

个人使用：

团队/企业使用：

龙虾虽好，但带出门就可能被悄悄拐跑。在多人“养殖”的环境下，记得先把池子围好。

白泽逐影（Telltale）智能体安全研究团队由杨哲慜副教授领衔，致力于研究大模型应用漏洞挖掘技术、构建面向新型智能化应用的安全攻防能力，为大模型应用的可信落地与稳健发展提供有力保障。

目前，团队已针对多类大模型应用产品开展了漏洞挖掘与安全检测工作，发现了数百个产品的安全风险，并及时向多家国内外企业进行了负责任披露，推动多项风险完成修复落地。相关成果已获亚马逊、腾讯、百度、字节跳动、快手、深信服等企业的认可，并在业内产生了积极影响。

复旦大学计算与智能创新学院副教授。研究方向为软件安全攻防技术，在网络安全顶级国际会议上发表论文 20 余篇，多项成果获网络空间安全顶级国际会议焦点论文、杰出论文奖等荣誉。曾获评新耀东方风采人物、上海市科学技术一等奖、中国计算机学会科学技术奖二等奖、上海市计算机学会科学技术奖一等奖。发现数万“零天”安全漏洞，影响谷歌、华为、三星、百度、阿里、腾讯、抖音、小米、高通等国内外知名企业及全球数十亿用户，获国家互联网应急中心授予“2021年最具价值漏洞奖”、“华为安全奖励计划特别贡献奖”等。

个人主页：https://yangzhemin.github.io/

联系方式：yangzhemin@fudan.edu.cn

复旦大学系统软件与安全实验室 23 级直博生，研究方向为大模型应用安全、新型移动应用的隐私治理与漏洞挖掘等。在网络安全顶级国际会议发表论文 2 篇，累计获得 300 余个分配有CVE、CNVD及NVDB编号的0-day漏洞，研究成果获亚马逊、华为、腾讯、字节跳动、快手、深信服等头部企业认可，获得“华为安全奖励计划特别贡献奖”。

复旦大学系统软件与安全实验室 24 级硕士生，研究方向为大模型应用安全、移动应用漏洞挖掘与自动化检测。相关研究工作累计产出数千个安全漏洞，2025年在华为、字节、百度、腾讯、小米、OPPO、360等知名厂商产品中发现 30+ 中高危及严重漏洞，并获得“华为安全奖励计划特别贡献奖”。

你的AI助手，很可能已经不是你的了！

第一步：安装工具

通过npm全局安装：

npm install -g whitzard-claw

第二步：启动终端扫描界面（TUI）或Web管理界面（WebUI）

1. 如果你是在服务器或终端环境中使用，可以启动 TUI 安全扫描界面：whitzard-tui

2. 如果你希望使用图形化界面，可以启动 WebUI 控制台：whitzard-webui

第三步：开始扫描并修复

启动后，在命令行或浏览器中开始扫描，即可查看可视化的安全检测结果，并进行相应的安全配置和一键修复操作。

<左右滑动，查看具体使用方式>

<左右滑动，查看具体使用方式>

微信等超级应用为小程序开发者提供了便捷的云端服务，如云数据库、云存储等，使开发者可以方便高效地管理业务数据。然而，便捷的开发环境并不等同于自动化的安全保障。研究发现，开发者在云资源访问控制实现上的普遍疏忽，正使小程序云端成为了新的安全重灾区。

近期，复旦大学系统软件与安全实验室小程序安全研究小组对小程序云服务进行了系统研究，揭示了数千个小程序存在云资源泄露风险，大量敏感数据在互联网中“裸奔”。该研究成果已发表于网络安全顶会NDSS 2026。

研究背景

问题核心：脆弱的身份屏障

工具设计

研究成果

白泽·鉴微小程序安全平台

研究团队

白泽er博士生邬梦莹分享了最新研究，获得NDSS '26杰出论文奖，详情可见往期推送。

电子邮件地址是通用的在线身份标识，但其别名机制却让邮件服务商和外部平台对“你是谁”产生分歧。白泽er首次系统分析这一身份混淆问题：服务商将带加号的别名地址视为同一用户的不同入口，而平台却常把它们当作独立账户。通过对28家邮件服务商和18个平台的实证评估，我们发现混乱远超预期——仅Gmail完整公开别名规则，11家服务商暗中支持特殊别名规则却无文档；因缺乏统一标准，平台无法识别由别名邮箱注册的多重账号；且双方均存在违反SMTP协议规定的情形。

真实案例显示，攻击者利用别名在npm上用一个邮箱注册139个账户发起垃圾攻击。用户研究更令人担忧：31.65%了解别名的参与者因规则不一误把钓鱼邮件当真，而自认懂别名的高学历、男性、技术人员反而更容易中招。我们呼吁行业规范别名机制的透明化，并贡献了OriginMail工具帮助平台识别别名背后的真实身份。

在该 Session 中，白泽er博士生张歆分享了来自移动应用安全小组围绕认证安全的研究成果，详细介绍见往期推送。

文章针对扫码登录、推送验证等跨设备认证机制，首次从“知情权、同意权、控制权”三项用户权利视角展开系统性安全性分析。团队揭示了工业界实现中普遍存在的上下文断裂与信息不对称问题，指出这些缺陷可能导致用户误授权恶意登录，甚至在撤销授权后仍面临“僵尸会话”持续泄露隐私的风险。通过对 27 个主流服务及 100 名用户的深度评估，我们揭示了实现与预期间的巨大鸿沟。目前，相关建议已获厂商积极反馈，如Zoho OneAuth已纳入其产品更新计划，为构建更透明、安全的跨设备认证生态提供了实证支撑。

白泽er博士生向柏澄在最新研究工作中，针对Windows文件系统中利用符号链接链篡改受保护文件的“链接追踪（LF）攻击”难题，研发了轻量级状态感知运行时防御系统LinkGuard。该系统通过创新的两阶段设计，结合动态主体过滤与基于有限状态机的规则匹配，克服了现有防御方案兼容性差、开销大且保护不全面的局限性；实验结果显示，LinkGuard在保持零误报和极低系统损耗（约3.4%）的前提下，成功拦截了100%的单步攻击及95.45%的多步真实漏洞攻击，为Windows文件系统安全提供了兼具高效能与高兼容性的自动化防御保障。

白泽er博士生史一哲揭示了小程序开发中存在的安全问题。目前，云开发已经成为小程序开发的主流模式。开发者无需自行维护服务器，就可以直接使用平台提供的云数据库、云存储等云服务来存储和管理用户数据，大大降低了开发成本和门槛。但白泽er在研究中发现，一些小程序在实现云端资源访问控制时存在安全缺陷，将敏感资源访问权限过度暴露给客户端，从而为攻击者留下了可乘之机，使得攻击者可以访问到其他用户的隐私数据、甚至下载云端机密文件等。为系统性评估这一问题，团队开发了自动化分析工具 ICREMiner，并对大量真实小程序进行深入分析，最终发现近三千个小程序存在相关安全缺陷，揭示了小程序生态中一个不容忽视的安全隐患。

博士生刘润昊针对现代Linux固件中“C语言与Lua脚本”混合架构带来的漏洞检测盲区，研发了自动化漏洞检测工具FirmCross，通过攻克Lua字节码反混淆、Lua空间污点识别及跨语言污点追踪等技术瓶颈，填补了传统工具无法有效分析混合架构Web服务的空白。在对11个厂商、73款固件的实测中，FirmCross的漏洞检测效能达到现有顶尖工具的6.82至14.5倍，成功挖掘出610个0-day漏洞，并已获得31个官方漏洞编号，显著提升了物联网设备固件的安全检测能力。

报告结束后，我们还与来自国内外的小伙伴们进行了交流与讨论，彼此分享各自的研究方向。我们的研究也引发了广泛关注，业界普遍认为这些发现揭示了当前生态中不容忽视的安全风险。在随后的交流环节中，大家进一步围绕小程序、移动应用生态等领域的后续安全发展趋势与防护思路展开了深入探讨。

简单来说，OpenClaw🦞 是一款超火的开源 AI 助手，主打一个“全能数字员工”：

• 技能树点满：不仅能帮你管文件、写代码，还能直接控制硬件（比如开摄像头、录音），简直是无所不能

• 哪里都能去：微信、QQ、飞书、Telegram……你在哪聊，它就在哪待命。只要群里 @ 一下，它立马开工

然而，能力越强，权限越高，一旦被坏人盯上，破坏力就越惊人

接下来，我们用两个真实案例，带大家看看：
一只“听话的龙虾”，是怎么一步步被别人利用的

春风有信，花开有期

在复旦大学张谧教授

带领的白泽AI团队里

有一群闪闪发光的「她」们

以专业为刃，以热爱为光

在科研和生活中一路“开挂”

展现属于女性科研人的实力与光芒

——白泽AI全体女神合影

当然，除了我们的女神们

也有更多优秀的男神们同样在发光

✨

科研从来不是独行

在平等、包容、互助的氛围里

我们都是并肩作战的队友

有人在前方探路、有人在后方托举

大家共同组成这支团队

当你需要的时候 师姐师兄们一直都在！

我们不设限、唯才是举。

无论你是谁，只要热爱AI安全、大模型安全，

都能在这里找到属于自己的科研舞台，

收获成长、实现价值、奔赴未来。

还没有关注复旦白泽战队？

公众号、小红书搜索：复旦白泽战队也能找到我们哦~

研究背景

    在多设备协同成为常态的当下，跨设备认证（XDAuth）已成为实现账号无缝、跨平台访问的核心机制，也是社交、电商、科技等领域的标配功能。

何为 XDAuth：用户在目标设备发起登录请求，通过已登录 / 存储安全凭证的可信认证设备完成授权，无需在目标设备输入密码，核心流程分为「发起登录 - 用户授权 - 完成登录」三步。目前主流实现方式为二维码认证、推送式认证、WebAuthn三种，凭借免密、便捷的体验，成为用户日常数字操作的重要组成部分。

跨设备认证（XDAuth）机制演示

     但这种设备分离的认证模式，也带来了先天的安全隐患：认证设备与目标设备的物理和上下文分离，让二者失去统一的场景线索，形成信息不对称——用户在认证设备上授权时，无法直观看到目标设备的实际环境，极易因信息缺失误批准恶意登录请求，其中QRLJacking（二维码劫持） 就是典型的攻击手段。攻击者伪造仿冒的登录二维码，诱导用户扫码，而因平台未提供任何目标设备相关信息，用户无法辨别二维码真伪，盲目点击授权后，攻击者即可直接接管用户账号，造成隐私泄露、账号被盗等严重后果。

QRLJacking 攻击案例

用户视角：三大用户权利

XDAuth 的工作流程

应用评估：跨设备认证安全现状

     团队选取 10 大品类 27 个主流服务，全覆盖三种 XDAuth 机制，评估发现行业普遍缺陷：

知情权：超半数平台让用户 “盲目授权”

    52%（14/27）的服务未提供任何目标设备 / 环境信息，仅 3 个服务披露授权权限范围，仅 1 个服务有设备风险提示；部分平台还存在信息质量差的问题，如 Keeper 仅展示原始 IP 地址、Wise 仅提供国家级地理位置，用户无法区分合法设备与攻击者设备。

同意权：设计漏洞为攻击提供可乘之机

控制权：认证容易控制难

    此外，团队向厂商披露问题后，Zoho OneAuth、GitHub等已积极回应，将改进方案纳入产品研发路线图。

团队为开发者提出核心设计建议：

你有没有试过在 Gmail 邮箱后面加 +1、+2 去无限白嫖诸如 Cursor、Netflix、Spotify 等各种软件或平台的新手试用期？

看起来像是不同的邮箱地址，但验证码却能被同一个邮箱接收，于是问题来了 —— 在网络上，邮箱常常就代表了作为一个人的身份，那这些邮箱到底是一个人？还是多个人？

神奇的邮箱别名

邮箱别名，一种神奇的机制，可以让一个邮箱“凭空变出”几十上百个邮箱地址。

他们看起来像是不同的人：

• alice@gmail.com

• al.ice@gmail.com

• alice+1@gmail.com

但在邮箱服务商眼里，他们是同一个人，因为这是为了给大家提供方便做出的机制，你就可以在steam和LinkedIn上使用不同的邮箱，然后根据收件箱的不同对邮件进行管理。

正确的使用方式👇

当然了，如果每个邮箱服务商都用同样的规则，都是加号和点，那确实是个好东西。

（那就没有我们这篇文章了。）

对，我们想说的就是，别名规则根本不是这样的。

走过路过可以先做个题试试👇

答案文末告诉你

通过一些预研尝试加头脑风暴，我们提出了（其实是发现了） 6 种别名邮箱构造方式，再带上了所有SMTP和IMF协议允许的字符（有32个标点符号其实能用），我们测试了 28 个主流邮箱服务商的别名规则。

别名邮箱构造方式

而后我们惊奇地发现，不同邮箱服务商所支持的别名规则都不太一样。

• 常见的：Gmail、Outlook 等支持 + 号后缀别名

• 抽象的：Eclipso 支持 !# 等多个符号的前缀别名

• 狡兔三窟的：Yandex、Runbox 等支持邮箱域名的替换

• 人人不一样的：中间也不一定是点，还有连字符下划线斜杠百分号

• 不听话的：SMTP说用户名必须大小写敏感，但大家都不敏感，那也算别名

有特殊规则的别名提供商，只有大小写问题的这里就不画了

既然大家的别名规则如此具有个性，想必会在用户手册或使用文档中详细说明吧。

遗憾的是，只有 Gmail 在使用文档中详细讲解了所支持的别名规则，其他家的规则只能靠大家来猜了。不仅不一致，还缺乏透明性。

这也是为什么大家都只知道加号是别名、误认为别名问题很好解决的原因，因为只有一家说了。

论文演讲完，来自IETF的专家感叹，他们几十年前定的标准确实没考虑到这么多，终于被发现了问题。

当邮箱别名机制遇上互联网平台

在互联网世界里，邮箱就像是一张“身份证”，注册账号、找回密码等都需要它。互联网平台的逻辑通常是“一个邮箱=一个用户”。

由此，邮箱服务商与互联网平台对于别名邮箱的认知出现了不一致。

• 发证机关（邮箱服务器，如 Gmail 等）：认为 alice@gmail.com 和 alice+1@gmail.com 是同一个人，作为别名机制，邮件都会发送到同一个收件箱。

• 查证机关（互联网平台，如 GitHub 等）：完全不知道别名机制（或者知道一点但不多），把 alice+1@gmail.com 当成一个全新的独立用户。

我们实测了全球 18 个顶级平台，下表展示了我们的测试结果，有字母就说明我们用别名注册成功了。

那很遗憾了，没有一个平台的注册校验能够完全抵御所有邮箱提供商的别名变体。npm和PyPI甚至不知道SMTP规定了邮箱域名部分是大小写不敏感的，把alice@example.com和alice@EXAMPLE.com也会当作两个人处理。

有平台努力了，比如Cloudflare确实把所有加号都当别名给禁止了，那咋了，那我还有前缀中缀换域名。

Microsoft的方案是只允许邮箱里出现连字符、下划线和点，那确实也有用，但真有连字符和下划线别名呀。

那么是否有人利用邮箱别名机制来干坏事呢？

有的兄弟，有的！我们收集了 GitHub 和 npm 平台上的用户邮箱，并发现有不少人使用别名邮箱进行账号注册，并且存在以一个邮箱注册多个账号的情况。

npm 上有攻击者利用单单一个 Gmail 邮箱，通过改大小写和加号的组合，硬生生注册了 139 个虚假账号，在短短十天内狂刷了 3,904 个恶意包做黑帽 SEO 推广。

聪明反被聪明误：别名误认攻击

当大家都习惯了 + 号是别名时，攻击者就可以在一个不支持别名机制的域名（如b.com）下注册 alice+1@b.com 来伪装成用户的熟人并发送钓鱼邮件，部分用户可能会因为“看起来像别名邮箱”而放松警惕。

别名误认攻击

为了研究这种攻击的可行性，我们精心设计了一份问卷并搭建平台进行用户调研。如下图所示，我们要求受试者检查邮件的发送者（即 From 字段），并判断邮件是否来源于左侧的联系人。

调研问卷与平台

原本我们只是想证明别名这个东西确实大家不太清楚不常见，但除此之外，我们找到了一个意料之外的发现：越是认为自己懂，越容易因为过度自信而上当受骗。

我们算了一下说自己懂别名和说自己不懂别名的受试者的被骗情况，发现“懂哥”们的受骗率将提升到31.65%，因为他们会乱猜规则（比如固执地认为有加号的都是别名）。不懂的哥们，只要全选no就好了。管你阿猫阿狗，长得不一样统统算不认识，安全的很。

谁最容易被自信骗，看图吧。特别是平时安全意识最强的CS学生，不懂的时候受骗率能压到0%（计算机安全课是上了真有用），懂了之后飙升至 35.29%。

不同人口因素在知晓别名与否的情况下的受骗率

OriginMail

如果你不了解也不想去了解复杂的邮箱别名机制，但又想判断两个类似邮箱之间的关系，那么可以尝试我们的开源小工具 OriginMail。我们总结了测试的 28 家邮箱提供商的别名规则，制作并开源了 OriginMail 检测工具，可以帮助大家把复杂的别名邮箱一键“打回原形”。项目地址：https://github.com/lab-rynth/OriginMail

OriginMail 能够检测的邮箱域名有下面展示的这么多！

OriginMail 支持的域名

结语

总而言之，我们系统梳理了不同邮箱服务商的别名机制，并分析了主流互联网平台、用户对于别名邮箱的处理方式，揭示了关于别名机制认知不一致所导致的安全问题。

当平台默认“一个邮箱 = 一个用户”而忽略了邮箱复杂的别名规则时，攻击者便可以轻易构造多个“合法身份”，滥用平台资源甚至发起攻击。

当用户自认为了解邮箱别名机制时，他们可能对“看起来像别名“的地址放松警惕，误判邮箱的真实性。这种认知上的自信与规则现实之间的落差，本身就成为新的攻击面。

我们呼吁邮箱服务商更加透明地公开并标准化别名规则，减少实现差异与规则模糊带来的滥用空间；也呼吁互联网平台建立完善的别名邮箱识别与验证机制，在注册、风控等流程中真正考虑别名邮箱机制等复杂性。

广泛引起学者兴趣，排队提问

研究团队

邬梦莹，复旦大学21级直博生，师从杨珉教授、张谧教授、洪赓助理研究员。主要研究方向为网络犯罪治理、互联网测量及智能体安全，在 ACM CCS、USENIX Security、NDSS 等国际顶级学术会议上发表7篇论文，其中一作5篇。相关成果在工业界及政府相关部门均有落地实战，取得良好效果。个人主页：https://funeoka-yumee.github.io/

陈佳涛，复旦大学24级硕士生，本科毕业于哈尔滨工业大学（深圳），主要研究方向为移动终端诈骗的检测与防护。

洪赓老师研究团队长期聚焦网络犯罪治理与人工智能安全治理等前沿方向，围绕国家网络安全与数字治理重大需求开展系统性研究。目前，已在 IEEE S&P、USENIX Security等国际顶级学术会议发表高水平论文二十余篇。获上海市技术发明一等奖、上海市决策咨询研究成果奖一等奖等；指导学生团队获得“挑战杯”全国大学生课外学术科技作品竞赛全国特等奖、全国大学生信息安全竞赛一等奖等荣誉。个人主页：https://security.fudan.edu.cn/members/faculty/hg/

复旦白泽战队

一个有情怀的安全团队

复旦白泽战队

一个有情怀的安全团队

团队简介

白泽 PoC 2025参会小记