文章总结： 本文介绍了团队使用GitHubSecurityLab开源AI框架进行自动化漏洞扫描的实践经验。通过基于LLM的工作流，团队在开源项目中发现了80多个漏洞，包括授权绕过和信息泄露等高危问题。文章详细拆解了工作流的威胁建模、问题建议和审计三阶段设计，并分享了在Outline等项目中发现的具体漏洞案例。框架已开源，用户可按照提供的步骤在自有项目上运行扫描。 综合评分： 85 文章分类： 代码审计,漏洞分析,安全工具,AI安全,安全开发

---

用 GitHub Security Lab 的开源 AI 框架做漏洞扫描，我们发现了什么

幻泉之洲

2026年3月22日 10:29 北京

在小说阅读器读本章

去阅读

过去几个月，我们团队用一套基于 LLM 的新型自动化审计工作流在开源项目中找漏洞，效果出乎意料。这套框架是开源的，任何人都能用来分析自己的项目。本文详细拆解了它的工作原理，并分享了几个关键的真实漏洞案例。

为什么我们选择自己摸索

过去几个月，我们一直在用 GitHub Security Lab Taskflow Agent，配合一组专门查找 Web 安全漏洞的新型审计工作流。结果发现，它们在寻找开源项目的高影响力漏洞方面非常成功。

作为安全研究员，我们习惯了把时间浪费在那些看似可能、实则无法利用的“漏洞”上。用了这些新工作流后，我们能把更多时间花在手动验证结果和撰写报告上。而且，现在我们上报的漏洞，严重性普遍都很高。很多是授权绕过或信息泄露漏洞，能允许一个用户登录成别人，或者访问他人的私人数据。

到目前为止，我们用它上报了80多个漏洞。写这篇文章时，已经有大约20个公开披露了。每当有新漏洞披露，我们就会持续更新我们的安全通告页面。

这篇文章，我会展示几个由这些工作流发现的高影响力具体案例，比如访问电商应用的购物车中的个人身份信息，或者用任意密码登录聊天应用。除了秀成果，我更想讲讲这些工作流是怎么运作的。因为只有分享知识，安全社区才能进步更快，这也是我们把框架开源、并让你能在自己的项目上轻松运行的原因。用的人越多，贡献的团队越多，大家一起消除漏洞的速度就越快。

怎么在你自己的项目上运行

想马上试试看？这套工作流是开源的，很容易自己上手跑起来！请注意：需要一个 GitHub Copilot 许可证，而且提示词会使用高级模型请求（跑工作流可能会产生很多工具调用，很容易消耗大量配额）。

1. 访问 seclab-taskflows 仓库，启动一个 codespace。

2. 等待几分钟让 codespace 初始化。

3. 在终端里运行：

   ./scripts/audit/run_audit.sh myorg/myrepo

对于一个中型仓库，跑完可能要一两个小时。完成后，它会打开一个 SQLite 查看器显示结果。找到“audit_results”表，查找“has_vulnerability”列被打了勾的行。

提示：由于 LLM 的非确定性，值得在同一个代码库上多次运行这些审计工作流。在某些情况下，第二次运行可能会产生完全不同的结果。此外，你可以用不同的模型跑这两次（比如第一次用 GPT-4o，第二次用 Claude 3.5 Sonnet）。

工作流也支持私有仓库，但你需要修改 codespace 配置，因为默认情况下它不允许访问你的私有仓库。

工作流到底是什么

Taskflows，或者说工作流，本质上是描述我们希望 LLM 执行的一系列任务的 YAML 文件。通过它们，我们可以编写提示词来完成不同的任务，并建立任务之间的依赖关系。seclab-taskflow-agent 这个框架负责按顺序执行任务，并把一个任务的结果传递给下一个。

比如说，审计一个仓库时，我们首先根据功能把仓库分成不同的组件。然后，针对每个组件，我们可能想收集一些信息，比如它接收不可信输入的入口点、预期的权限、组件的用途等等。这些结果随后被存入数据库，为后续任务提供上下文。

基于这些上下文数据，我们就可以创建不同的审计任务。目前，我们有一个任务是为每个组件提出一些通用问题，另一个任务则仔细审计每个被提出的问题。当然，也可以创建其他任务，比如专门聚焦于某一类问题的任务。这些任务就构成了我们在一个工作流文件中指定的任务列表。

我们选择拆分成多个小任务，而不是用一个巨型的提示词，主要是因为 LLM 的上下文窗口是有限的，复杂多步骤的任务经常无法正确完成，比如漏掉某些步骤。即便某些 LLM 有了更大的上下文窗口，我们发现工作流模式仍然有用，它能让我们控制和调试任务，也能完成更大更复杂的项目。

seclab-taskflow-agent 还可以异步地（像一个 for 循环）在许多组件上运行同一个任务。在审计过程中，我们经常对每个组件复用相同的提示词和任务，只改变细节部分。这个框架让我们可以定义模板化的提示词，遍历组件，并在运行时替换组件特定的细节。

从专项检查走向通用审计

在用 seclab-taskflow-agent 处理 CodeQL 警报之后，我们决定不再把自己局限于特定类型的漏洞，开始探索用这个框架做更通用的安全审计。给 LLM 更多自由度的主要挑战在于幻觉和误报的增加。毕竟，之前在处理 CodeQL 警报上的成功，部分原因是我们给了 LLM 一套非常严格、定义明确的指令和标准，这样每个阶段的结果都能被验证，看看指令是否被遵循。

所以，我们现在的目标，是找到一种好方法，既能让 LLM 自由地寻找不同类型的漏洞，又能把幻觉控制在可接受的范围。

接下来，我会展示我们如何仅靠工作流设计和提示词工程，就用智能体工作流发现了高影响力、高真阳性率的漏洞。

通用工作流设计思路

为了在工作流设计层面减少幻觉和误报，我们的工作流从一个威胁建模阶段开始。在这个阶段，仓库会根据功能和各种信息（如入口点）被划分为不同的组件，并收集各个组件的预期用途。这些信息帮助确定每个组件的安全边界，以及它暴露于不可信输入的程度。

通过威胁建模阶段收集的信息，然后被用来决定每个组件的安全边界，以及判断什么应该被视作安全问题。例如，在一个设计为执行任意用户输入脚本的 CLI 工具中发现命令注入，这可能是个 bug，但不能算安全漏洞，因为能利用该 CLI 工具注入命令的攻击者本来就已经可以执行任何脚本了。

在提示词层面，发现的预期用途和安全边界会被用在提示词中，提供严格的指导方针，以判断发现的问题是否应被视为漏洞。

你需要参考组件笔记中的意图和威胁模型，来确定某个问题是有效的安全问题还是预期功能。你可以获取入口点、Web入口点和用户操作来帮助你确定组件的预期用途。

直接让 LLM 在代码库中“寻找任何类型的漏洞”这样模糊的指令，会产生包含大量幻觉问题的糟糕结果。理想情况下，我们想模拟一个分类环境：我们有一些潜在问题作为分析的起点，然后要求 LLM 应用严格的标准来判断这个潜在问题是否有效。

为了启动这个过程，我们把审计任务分成两步：

• 首先，我们让 LLM 遍历仓库的每个组件，并提示它可能在该组件中更易出现的漏洞类型。
• 然后，这些建议被传递给另一个任务，在那里它们将根据严格的标准被审计。

在这个设置下，第一步的建议就像是被某个“外部工具”标记出来的一些不准确的漏洞警报，而第二步则充当分类步骤。虽然这看起来像是一个自我验证的过程——但通过把它分解成两步，每步都有全新的上下文和不同的提示词——第二步能够对建议提供准确的评估。

威胁建模阶段

在处理自动代码扫描工具标记的警报时，我们发现很大比例的误报是由于不恰当的威胁建模导致的。大多数静态分析工具不考虑源代码的预期用途和安全边界，经常给出没有安全影响的结果。例如，在一个反向代理应用中，自动化工具标记的许多 SSRF 漏洞可能属于应用的预期用途；而一些用于持续集成流水线的 Web 服务，其设计就是在沙盒环境中执行任意代码和脚本。在这些应用中，没有沙盒逃逸的远程代码执行漏洞通常不被视为安全风险。

考虑到这些注意事项，先浏览一遍源代码来了解代码的功能和预期目的是值得的。我们将这个过程分成以下几个任务：

• 识别应用：GitHub 仓库作为审计边界并不完美。它可能是一个更大系统中的单个组件，也可能包含多个组件。因此，识别并单独审计每个组件以匹配不同的安全边界并保持范围可管理是值得的。identify_applications 这个工作流就是做这个的，它让 LLM 检查仓库的源代码和文档，并按功能划分组件。
• 识别入口点：我们识别每个入口点如何暴露于不可信输入，以更好地评估风险并预测可能的漏洞。因为“不可信输入”在库和应用之间差异很大，我们为每种情况提供了单独的指导方针。
• 识别Web入口点：这是额外的一步，用于收集有关应用中入口点的更多信息，并附加特定于Web应用入口点的信息，比如标注访问特定端点所需的HTTP方法和路径。
• 识别用户操作：我们让 LLM 审查代码，识别在正常操作下用户可以访问的功能。这明确了用户的基线权限，有助于评估漏洞是否能实现权限提升，并为组件的安全边界和威胁模型提供信息。根据组件是库还是应用，我们有不同的指令。

在上述每个步骤中，收集到的关于仓库的信息都会被存入数据库，包括仓库中的组件、它们的入口点、Web入口点和预期用途。这些信息随后可供下一阶段使用。

问题建议阶段

在这个阶段，我们指示 LLM 利用从上一步收集的关于组件入口点和预期用途的信息，为每个组件建议一些漏洞类型，或者指出一个高风险的大致区域。我们特别强调组件的预期用途及其来自不可信输入的风险：

基于以下几点做决定：

• 这个组件是否可能接收不可信的用户输入？例如，远程Web请求或IPC、RPC调用？
• 这个组件的预期目的和功能是什么？它是否允许高权限操作？ 它是否旨在为所有用户提供这些功能？或者是否有复杂的访问控制逻辑参与？
• 组件本身也可能有自己的 README.md（或其子目录可能有 README.md）。查看这些文件有助于理解组件的功能。

我们也明确指示 LLM 不要建议低严重性或通常不被视为安全的问题：

但是，你仍应注意不要包含低严重性问题或需要不现实攻击场景的问题，例如错误配置或系统已被攻陷的情况。

总的来说，我们在这个阶段保持相对宽松的限制，允许 LLM 自由探索并建议不同类型的漏洞和潜在安全问题。目的是为实际的审计任务提供一个合理的聚焦领域和漏洞类型集合，作为起点。

我们遇到的一个问题是，LLM 有时会开始审计它自己建议的问题，这就违背了头脑风暴阶段的目的。为了防止这种情况，我们指示 LLM 不要审计那些问题。

问题审计阶段

这是工作流的最后阶段。一旦我们收集了关于仓库需要的所有信息，并建议了一些要关注的漏洞类型和安全风险，工作流就会遍历每个被建议的问题，通过审查源代码来审计它们。在这个阶段，任务从一个全新的上下文开始，以仔细审查前一阶段建议的问题。这些建议被认为是未经验证的，这个工作流被指示去验证它们：

建议的问题尚未得到妥善验证，之所以被建议只是因为它们是这类应用中常见的问题。你的任务是审计源代码，检查这类问题是否存在。

为避免 LLM 提出在组件上下文中与非安全相关的问题，我们再次强调必须考虑预期用途：

你需要参考组件笔记中的意图和威胁模型，来确定某个问题是有效的安全问题还是预期功能。

为避免 LLM 幻想出不切实际的问题，我们还指示它提供一个具体且现实的攻击场景，并且只考虑源于源代码错误的问题：

不要考虑通过窃取凭证等方式绕过身份验证的场景。我们只考虑从源代码本身可实现的情况。 … 如果你确信存在漏洞，那么你必须提供一个现实的攻击场景，包含所有涉及的文件和行号详细信息，并说明攻击者利用该漏洞能获得什么。只有当攻击者能通过执行组件未预期的操作获得权限时，才将该问题视为漏洞。

为更进一步减少幻觉，我们还指示 LLM 从源代码中提供具体证据，包括文件路径和行号信息：

保存审计笔记，确保包含所有相关的文件路径和行号。仅仅陈述一个端点，例如 用户更新/删除端点中的IDOR (PUT /user/:id) 是不够的。我需要有具体的文件和行号。

最后，我们也指示 LLM 组件中可能根本没有漏洞，不应该无中生有：

记住，建议的问题只是推测，可能根本不存在漏洞，得出结论说没有安全问题也是可以的。

这个阶段的重点是在遵循严格指导方针的同时提供准确结果，并为发现提供具体证据。有了这些严格的指令，LLM 确实拒绝了许多不切实际和无法利用的建议，幻觉非常少。

第一个原型设计时，防幻觉是优先考虑，这引出一个疑问：它会不会变得过于保守，拒绝大多数漏洞候选，从而无法浮现真正的问题？在我们对几个仓库运行工作流后，答案就清楚了。

工作流发现的三个漏洞实例

这部分，我会展示三个由工作流发现并已公开披露的漏洞实例。到目前为止，我们一共发现并上报了超过80个漏洞。所有已披露的漏洞我们都发布在我们的安全通告页面上。

Outline 中的权限提升（CVE-2025-64487）

我们的信息收集工作流是针对 Web 应用优化的，所以我们首先把审计工作流指向了一个叫 Outline 的协作 Web 应用。

Outline 是一个多用户协作套件，它的某些特性我们特别感兴趣：

• 文档有所有者和不同的可见性设置，权限按用户和团队分配。
• 像这样的访问规则很难用 SAST 工具分析，因为它们使用自定义的访问机制，而现有的 SAST 工具通常不知道一个普通“用户”应该能执行什么操作。
• 仅仅通过阅读源代码（当然，除非规则是你自己设定的），这类权限方案对人类来说通常也很难分析。

结果很成功：我们的工作流在第一次运行就发现了授权逻辑中的一个 bug！

审计结果中的笔记是这样的：

审计目标：outline/outline 的 server (后端API) 组件（组件 ID 2）中不当的成员管理授权。

总结结论：存在真实的权限提升漏洞。文档组成员资格修改端点 (documents.add_group, documents.remove_group) 使用较弱的 “update” 权限进行授权，而不是用户成员变更所需的更强的 “manageUsers” 权限。因为 “update” 权限可以通过仅拥有文档的 ReadWrite 成员资格来满足，一个非管理员文档协作者可以授予（或撤销）组成员资格——包括授予 Admin 权限——从而提升他们自己（如果他们是被添加组的成员）和其他组成员的权限。这允许了原本不打算让仅仅是ReadWrite协作者执行的操作（manageUsers, archive, delete等）。

阅读基于 TypeScript 的源代码并在测试实例上验证后，我们证实它确实如描述那样可利用。此外，描述的攻击步骤也很精准：

前提条件：

• 攻击者是一个普通团队成员（非管理员），不是访客，对文档 D 拥有直接的 ReadWrite 成员资格（或通过授予ReadWrite的组），但没有 Admin 权限。
• 攻击者是同一团队中现有组 G 的成员（他们不需要是 G 的管理员；根据组策略，拥有组读取权限即可）。

步骤：

1. 攻击者调用 POST documents.add_group (server/routes/api/documents/documents.ts 第1875-1926行)，消息体为： {  “id”: “”,  “groupId”: “”,  “permission”: “admin” }
2. 授权路径：   – 第1896行：authorize(user, “update”, document) 成功，因为攻击者拥有 ReadWrite 成员资格（document.ts 第96-99行允许 update）。   – 第1897行：authorize(user, “read”, group) 对任何非访客的同团队成员都成功（group.ts 第27-33行）。   没有进行 “manageUsers” 检查。
3. 代码创建或更新了具有 Admin 权限的 GroupMembership（第1899-1919行）。
4. 由于攻击者是组 G 的成员，他们有效的文档权限（通过 groupMembership）现在包含了 DocumentPermission.Admin。
5. 拥有 Admin 成员资格后，攻击者现在满足了以下操作中使用的 includesMembership(Admin) 条件：   – manageUsers (document.ts 第123-134行)，使得可以添加/删除任意用户 documents.add_user / documents.remove_user（第1747-1827行，第1830-1872行）。   – archive/unarchive/delete (document.ts档案策略第241-252行；删除第198-208行)，影响内容完整性。   – duplicate, move及其他类管理员功能（如 duplicate 策略第136-153行；move 第155-170行），超出了原本的 ReadWrite 范围。

利用这些指令，一个低权限用户可以将任意组添加到他仅被允许“更新”的文档中（该用户并不拥有此类变更通常所需的“manageUsers”权限）。

Outline 项目在三天内就修复了这个漏洞和我们报告的另一问题！

购物车的“灾难”（CVE-2025-15033 和 CVE-2026-25758）

直到我们把工作流指向清单上的第一个在线商店，我们才意识到会在电商应用的购物车逻辑中发现什么系统性问题。在基于 PHP 的 WooCommerce 项目中，工作流立刻找到了一种让普通登录商店用户查看所有访客订单的方法——包括个人身份信息（姓名、地址和电话号码）。报告后，Automattic 迅速发布了一个更新和一个配套博客文章。

对这个漏洞产生兴趣后，我们在智能体待审计的应用清单中又添加了一些其他的电商应用。果然，我们找到了更多漏洞。基于 Ruby 的热门 Spree commerce 应用包含两个类似的漏洞。更严重的那个漏洞允许未认证用户通过简单地递增一个顺序号，来枚举所有访客订单的地址（和电话号码）。

我们在 Spree 上的“漏洞狩猎狂欢”并未停止。工作流还在另外两个电商应用中发现了类似问题。这些授权逻辑的 bug 已经存在多年未被发现。

用任意密码登录 Rocket.Chat（CVE-2026-28514）

（这不是密码认证该有的样子！）

偶尔你会觉得难以置信。工作流在 Rocket.Chat 中的这个发现就是其中之一。

当你的智能体返回一条这样的笔记时：

漏洞：account-service 中的密码认证绕过允许使用任意已设置密码的用户登录。

你可能一开始很难相信。

当你继续阅读输出时：

根本原因：

• ee/apps/account-service/src/lib/utils.ts:60-61：validatePassword 返回 Promise (bcrypt.compare(…))。
• ee/apps/account-service/src/lib/loginViaUsername.ts:18-21：const valid = user.services?.password?.bcrypt && validatePassword(password, user.services.password.bcrypt); 但没有对 Promise await；由于 Promise 是真值，所以当 bcrypt 哈希存在时，if (!valid) return false; 永远不会触发。
• ee/apps/account-service/src/lib/loginViaUsername.ts:23-35：继续生成新的登录令牌并保存，返回 { uid, token, hashedToken, tokenExpires }。

可能就更合理一些，但你仍然不信。结果发现，这个可疑的发现存在于 Rocket.Chat 基于微服务的设置中。在那个特定设置里，Rocket.Chat 通过其 DDP Streamer 服务暴露了用户账户服务。

一旦我们的 Rocket.Chat 测试环境正常工作，我们就必须编写概念验证代码来利用这个潜在漏洞。智能体的笔记已经包含了我们可以用来通过 Meteor 的 DDP 协议连接到端点的 JSON 构造。

我们连接到 DDP streamer 服务的 WebSocket 端点，确实：确实有可能使用任意密码登录到暴露的 Rocket.Chat DDP 服务。登录后，还可以执行其他操作，比如连接到任意聊天频道并监听发送到这些频道的消息。

这个问题的技术细节很有趣（也很吓人）。Rocket.Chat 主要是基于 TypeScript 的 Web 应用，使用 bcrypt 存储本地用户密码。用来比较密码和存储哈希的 bcrypt.compare 函数返回一个 Promise，这反映在 Rocket.Chat 自己的 validatePassword 函数中，它返回 Promise：

export const validatePassword = (password: string, bcryptPassword: string): Promise =>    bcrypt.compare(getPassword(password), bcryptPassword);

但是，在使用这个函数时，没有等待（await）这个 Promise 的值得到确定：

const valid = user.services?.password?.bcrypt && validatePassword(password, user.services.password.bcrypt);

if (!valid) {    return false; }

这导致 validatePassword 的结果与 true 进行了与运算。由于在 JavaScript 中，返回的 Promise 总是“真值”，所以当用户设置了 bcrypt 密码时，布尔值 valid 总是为 true。

撇开严重性不谈，有趣的是 LLM 能够发现这个相当微妙的 bug，追溯多个文件，并得出正确的结论。

我们从数据中学到了什么

在约40个仓库（主要是多用户Web应用）上运行工作流后，LLM 提出了1003个问题（潜在漏洞）。经过审计阶段，139个被标记为存在漏洞，意味着LLM认为它们可利用。在对结果进行去重（重复发生是因为每个仓库平均运行了几次并汇总了结果）后，我们最终得到91个漏洞，我们决定在上报前手动检查它们。

• 我们拒绝了 20 个（22%）结果，作为误报，因为我们无法手动复现。
• 我们拒绝了 52 个（57%）结果，因为严重性低：影响潜力非常有限的问题（例如，只返回 HTTP 状态码的盲 SSRF；安装阶段需要恶意管理员等）。
• 我们只保留了 19 个（21%）我们认为影响力足够上报的结果，全部是严重漏洞，大多数具有高或严重级别（例如，无需特定条件即可触发、影响机密性或完整性的漏洞，如个人数据泄露、系统设置覆盖、帐户接管等）。

这些数据是在使用 GPT-4o 作为代码分析和审计任务模型时收集的。请注意，自收集这些数据以来，我们已经在更多仓库上运行了工作流，所以下表并不代表我们收集的所有数据和我们上报的所有漏洞。

| 问题类别 | 总计 | 存在漏洞 | 漏洞率 | | — | — | — | — | | IDOR/访问控制问题 | 241 | 38 | 15.8% | | XSS | 131 | 17 | 13.0% | | CSRF | 110 | 17 | 15.5% | | 认证问题 | 91 | 15 | 16.5% | | 安全配置错误 | 75 | 13 | 17.3% | | 路径遍历 | 61 | 10 | 16.4% | | SSRF | 45 | 7 | 15.6% | | 命令注入 | 39 | 5 | 12.8% | | 远程代码执行 | 24 | 1 | 4.2% | | 业务逻辑问题 | 24 | 6 | 25.0% | | 模板注入 | 24 | 1 | 4.2% | | 文件上传处理问题（不含路径遍历） | 18 | 2 | 11.1% | | 不安全反序列化 | 17 | 0 | 0.0% | | 开放重定向 | 16 | 0 | 0.0% | | SQL注入 | 9 | 0 | 0.0% | | 敏感数据暴露 | 8 | 0 | 0.0% | | XXE | 4 | 0 | 0.0% | | 内存安全 | 3 | 0 | 0.0% | | 其他 | 67 | 7 | 10.6% |

LLM 尤其擅长发现逻辑漏洞

数据中突出的一点是“业务逻辑问题”高达 25% 的比例，以及大量的 IDOR 问题。事实上，被标记为存在漏洞的 IDOR 问题的总数超过了后两个类别（XSS 和 CSRF）的总和。总体印象是，LLM 在理解代码空间、追踪控制流、同时考虑应用的访问控制模型和预期用途方面做得非常出色。这大概也符合我们对擅长代码审查任务的 LLM 的预期。这也让它非常擅长发现传统工具难以发现的逻辑漏洞。

LLM 擅长拒绝低严重性问题和误报

有趣的是，所有误报都不能算是幻觉。包括误报在内的所有报告都有合理的证据支持，我们可以根据报告追踪到端点并应用建议的负载。许多误报是由于代码之外更复杂的情况造成的，比如上面提到的浏览器对 XSS 的缓解措施，或者我们认为是人工审计员也可能犯的合理错误。例如，当存在多层身份验证时，LLM 有时可能会漏掉某些检查，导致误报。

自那以后，我们测试了更多仓库，上报了更多漏洞，但漏洞和仓库之间的比例大致保持不变。

为了展示工作流的扩展性以及如何将额外信息融入其中，我们创建了一个新的工作流，在审计阶段后运行，它结合了我们新获得的知识来过滤掉低严重性漏洞。我们发现，这个工作流可以过滤掉大约 50% 的低严重性漏洞，同时也有少量我们上报的、处于临界状态的漏洞被标记为低严重性。工作流和提示词可以根据用户自己的偏好进行调整，但对我们来说，我们倾向于让它更包容一些，以免错失有影响力的东西。

LLM 擅长威胁建模

总的来说，LLM 在威胁建模方面表现良好。在实验中，我们在多个具有不同威胁模型的应用上测试了它，例如桌面应用、多租户 Web 应用、设计在沙盒环境中运行代码的应用（设计上的代码注入）以及反向代理应用（SSRF 行为是预期功能的应用）。工作流能够考虑到这些应用的预期用途并做出合理的判断。工作流在处理桌面应用的威胁建模时最困难，因为通常不清楚运行在用户桌面上的其他进程是否应被视为可信。

我们也观察到 LLM 有一些出色的推理，它排除了那些无法获得权限提升的问题。例如，在一个案例中，LLM 注意到虽然访问控制存在不一致，但该问题并未给攻击者带来相对于手动复制粘贴操作的任何优势：

安全影响评估：

一个仅对文档拥有读访问权限（无更新权）的用户，只要他们对目标集合拥有 updateDocument 权限，就可以复制该文档。这允许他们创建一个可编辑的内容副本，而这些内容他们本来就能读取。这并不会授予他们对其他文档的额外访问权限，也不会绕过原文档的保护；任何拥有读权限的用户都可以将内容手动复制粘贴到一个他们被允许创建的新文档中（根据创建文档集合策略，通常允许非访客、非仅查看成员在ReadWrite集合中创建）。

我们还看到在推理中用到了一些更复杂的技术。例如，在一个在沙盒化 nodejs 环境中运行脚本的应用中，LLM 建议了以下逃逸沙盒的技术：

在 Node 的 vm 中，将任何外层领域的函数传入上下文化的沙盒会通过其 constructor 属性泄露该函数的外层领域 Function 构造函数。从沙盒内部：  const F = console.log.constructor; // 外层领域的 Function  const hostProcess = F(‘return process’)(); // 主机进程对象  // 通过主机的动态导入绕过模块允许列表  const cp = await F(‘return import(“node:child_process”)’)();  const out = cp.execSync(‘id’).toString();  return [{ json: { out } }];

存在主机函数（console.log, 计时器, require, RPC 方法）就足以获得主机 Function 构造函数并逃逸沙盒。允许列表中的 require-resolver 被绕过，方法是构造主机领域函数并使用内置模块（如 node:child_process）的动态导入，这不会经过沙盒的自定义 require。

虽然由于其他缓解因素，结果证明这是个误报，但它展示了 LLM 的技术知识。

行动起来！

我们用来发现这些漏洞的工作流是开源的，很容易在你自己的项目上运行，希望你也试试！我们也鼓励你编写自己的工作流。这篇文章展示的结果只是可能性的冰山一角。还有其他类型的漏洞有待发现，还有其他与安全相关的问题，比如分类 SAST 结果或构建开发环境设置，我们认为工作流也能帮上忙。在我们的仓库开启讨论，让我们知道你构建了什么！

---

免责声明：

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

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

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

本文转载自：幻泉之洲 《用 GitHub Security Lab 的开源 AI 框架做漏洞扫描，我们发现了什么》