一个开箱即用的 AI 模糊测试器在数百万设备内置的 FatFs 中发现七个缺陷

这是什么？

2026 年 7 月 1 日，安全公司 runZero 披露了 FatFs 中的七个漏洞。FatFs 是一个小型 C 语言库，使嵌入式设备能够读写 U 盘和 SD 卡所用的 FAT 与 exFAT 格式。它并不冷门：它内置于安全摄像头、无人机、工业控制器、加密货币硬件钱包以及无数其他实时系统的固件之中。在受影响最严重的设备上，一个被做过手脚的存储卷或固件镜像即可破坏内存并运行攻击者代码——而由于许多嵌入式芯片缺乏手机和 PC 上的内存保护，runZero 直白地概括其影响：「任何物理访问都会导致越狱」。

这些漏洞本身是常见的内存安全错误。真正值得关注的是它们被发现的方式。runZero 早在 2017 年就人工审计过 FatFs，几乎没有可上报的内容。2026 年 3 月再次回来时，团队用一套几乎完全开箱即用的组合对准同一份代码——Visual Studio Code、处于「auto」模式的 GitHub Copilot 以及几条普通提示词——让模型构建了一个模糊测试器。这套测试装置浮现出人工审计遗漏的漏洞，并帮助确认它们是可达的。

工作原理

模糊测试器是一种向程序注入畸形输入、直到出现崩溃的工具。为文件系统解析器编写一个好的模糊测试器通常需要真功夫：必须理解磁盘上的结构、生成变异的磁盘镜像，并搭建一个能够挂载它们并捕获崩溃的测试装置。在本例中，LLM 从自然语言提示词出发生成了这套框架，最终的模糊测试器对解析代码的探索比一次性人工复查更加彻底。

七个发现都遵循同一模式。设备尝试读取一个被故意破坏的存储卷或更新镜像，而 FatFs 错误地处理了这些数据。最突出的问题是挂载 FAT32 卷的代码中的整数溢出：错误的算术产生了虚假的文件大小，后续代码将其当作真实的读取长度——在真实硬件上，这可能演变为内存破坏和代码执行。其余问题包括：一个溢出小缓冲区的 exFAT 卷标字段；溢出许多项目在 FatFs 外围所加封装代码的长文件名；缓存处理中的一处计算回绕，在碎片化卷上悄然破坏数据；一个 exFAT 除零错误，可在更新过程中使硬件「变砖」；以及一次越界读取，泄露先前已删除文件的残留字节。runZero 将这组漏洞评级为 CVSS 中到高，无一为严重级，并在一个公开的配套代码仓库中提供了概念验证磁盘镜像和基于 QEMU 的测试装置，供厂商复现并验证修复。

runZero 明确表示，这并非一次孤立事件。同样的模式已经持续了一年多：Google 的 Big Sleep 智能体在 2024 年底于 SQLite 中发现了一个传统模糊测试遗漏的、真实且可利用的内存漏洞；2026 年 6 月，一个自主智能体在 FFmpeg——另一个广泛嵌入的 C 库——中浮现了 21 个内存安全漏洞。团队的观点是：如果一个几乎开箱即用的 AI 流水线能找到这些漏洞，任何人都能。

为何重要

这里改变的有两件事，而只有一件与代码有关。第一件是发现的经济学。审计一个存在了数十年的 C 解析器过去需要专家的时间与耐心；如今，一名手握大众化编码助手的开发者可以在一个下午搭起有效的模糊测试装置。这为防御者降低了门槛——同样也为攻击者降低了门槛，他们不再需要深厚的文件系统专业知识就能去寻找下一个 FatFs。

第二件是披露渠道，它并未随发现能力一同扩展。FatFs 由单一开发者维护，runZero 表示曾多次尝试联系该维护者，并让日本的 JPCERT/CC 协调中心介入，但均无回应。结果是：内存破坏类漏洞没有上游修复，没有安全邮件列表，也没有渠道告知众多内置 FatFs 的产品它们已暴露。七个漏洞中只有一个——由畸形分区表引发的拒绝服务——在上游 R0.16 版本中得到修复。其余全部落到下游厂商身上，须自行修补。runZero 点名了受影响的平台，包括 Espressif ESP-IDF、STMicroelectronics STM32Cube、Zephyr、MicroPython、ArduPilot、RT-Thread、Mbed、Samsung TizenRT 以及 SWUpdate 更新器——这将问题推向消费级 IoT、工业设备、无人机和硬件钱包。runZero 引用的先例是 PixieFail，即厂商迟迟未修的 2024 年一批固件漏洞；FatFs 形态相同，而修复渠道更弱，因为根本没有一个有回应的上游。截至披露之时，尚无相关攻击被报告。

防御

令人不安的教训是：「没人费心去看」已不再是一种防御，因为「看」已经变得廉价。构建者与运营者都有具体的抓手。

如果你交付会接触 FAT 或 exFAT 介质的固件，请找到产品中的那份 FatFs 副本，把它当作处理攻击者可控输入的不可信解析器来对待。审计其外围的封装代码——诸如「strcpy 到固定缓冲区」的模式正是这几个漏洞的落点——并仔细检查你如何计算文件名与文件大小。引入上游 R0.16 版本以获取分区表修复，并自行回移植或缓解内存破坏问题，因为并不存在上游补丁。在硬件允许之处，启用内存保护（MPU/MMU 区域、栈金丝雀、W^X），使解析漏洞只导致崩溃而非越狱。可以考虑针对你实际交付的确切 FatFs 构建与封装，运行你自己的 AI 辅助模糊测试；发现这些漏洞的同一套大众化工具，也能在攻击者之前找到下一批。

如果你运营受影响的设备，请把物理端口和固件更新渠道当作攻击面，而非便利设施。限制谁能向自助终端、摄像头、ATM 和控制器插入介质；校验并签名固件镜像，使畸形更新无法被强行推入；并关注厂商补丁，同时明白：对于像这样的「孤儿」依赖，补丁可能需要数年才会到来。

状态

参考（runZero，2026 年 7 月 1 日）	CVSS	影响
CVE-2026-6682	7.6（高）	FAT32 挂载整数溢出 → 内存破坏，可能代码执行；可经某些固件更新触及
CVE-2026-6687	7.6（高）	exFAT 卷标缓冲区溢出（内存破坏的立足点）
CVE-2026-6688	7.6（高）	长文件名溢出 FatFs 常见封装代码
CVE-2026-6685	6.1（中）	缓存处理中的计算回绕 → 碎片化卷上的静默数据破坏
CVE-2026-6683	4.6（中）	exFAT 除零；在更新流程中可使硬件「变砖」
CVE-2026-6686	4.6（中）	越界读取：泄露先前已删除文件的数据
CVE-2026-6684	4.6（中）	畸形 GPT 分区表在挂载时挂起——唯一在上游修复者（FatFs R0.16）

关键日期：2017 年——runZero 的人工审计几乎一无所获。2026 年 3 月——团队用 VS Code + 处于「auto」模式的 GitHub Copilot 重新审计，LLM 构建了模糊测试器。2026 年 7 月 1 日——协调披露并附公开 PoC；尽管 JPCERT/CC 介入，上游仍无回应。范围说明：可利用性因设备、内存保护以及各厂商如何封装 FatFs 而差异极大。