研究人员在Prusa MK4S 3D打印机中发现14个漏洞，可远程执行代码

cd .. RSS Never gonna print you up！ 2026年11月2日 21:30 CET • 22分钟阅读 #security#responsible-disclosure#vulnerability#3d-printing#iot-security#firmware#ai 目录 注：本文的发布与 Prusa 协同进行，并与官方安全公告同时公开。Prusa 已在 Buddy 固件 >7.0.0 中修复了本文中的所有发现，所以如果你的打印机在文末的列表中，请立即更新。我也已为所有发现申请了 CVE 编号，应该很快就会下来。如果你知道如何加快编号分配，我很想听听！

嘿 Rick，你在我的打印机上干什么？！ 八月里我花了整整一周时间尝试攻破我的 MK4S，结果事态升ji得相当厉害：14 项发现、大约 23 个独立缺陷，还有一条最终让打印机主控运行了我通过网络发送给它的代码的攻击链。没错，完整的 RCE。

这篇文章讲的是这些发现，以及 Prusa 处理整件事的方式。

我是一名自由职业者，从事平台工程、SRE 和数据库相关工作——安全研究是我的“爱好”（你知道的，在拿钱的计算机工作之后休息一下，换另一种计算机工作……）。我喜欢通过破坏东西来了解内部原理。我参加 CTF 多年（并深受 LiveOverflow 启发，尝试理解逆向和 pwn），最近也在生产环境的 Web 应用中做出了一些真实发现，我会主动为客户扫描这些应用（顺便说一句，你可以按项目雇佣我！）。不过固件和硬件对我来说算是新领域。所以，是的，在此之前我从未写过一行 Cortex-M 汇编，也从未需要写过。

环境配置基本是最基础的那种：我自己的 MK4S 以及它当时运行的已签名上游镜像，那个版本在当时还算新（6.5.7，build 6.5.7+12836）——而我手里有 Opus 4.8 和一个 fuzzer。我从两个地方入手：G-code 解析和 Prusa Connect，依据的是一贯的理论：先从用户输入进入的地方寻找漏洞，而这也正是我发现最严重 bug 的地方。更多的漏洞出现在 USB 和 FAT 路径（同样是用户输入）以及传输恢复代码中，另外在 MMU 和 EEPROM 方面还有一些较小的缺陷。

迄今为止最困难的部分是控制流原语，我有一堆看起来可用的候选分发点，而实际上只有一个能用于 RCE。其余的被逐一排除，其中大部分（虽然不是全部！）排除工作是机械性的，我可以交出去再检查。

我发给 Prusa 的披露包包含了我构建的整个工作树，包括我使用的方法、脚本等。我有意将这种方法的所有痕迹都移交给了他们，因为尽管厂商需要的是缺陷和行号，但我觉得把我为整个行动构建的框架给他们、让开发者能够复现我的流程（如果他们愿意的话，我希望他们愿意！）可能会有好处。我想做出明显的区分，并建立信任，证明我发现的确实是真实的（稍后会详细说明……）且可复现，因此我对披露包做了分离。不过，在手动审查之后，我仍然有足够的信心认为第二批（源码验证）集合中的发现是真实的。

我给 Prusa 发了两个包。第一个包含四项发现，其中三项在物理打印机上得到确认，既有打印机自己写出的崩溃转储，也有对控制器的完全接管。第四项是 MMU 侧的一个 off-by-one，仅经过源码验证（下面会详细说明）。第二个包包含其余十项，这些在 AddressSanitizer 下或仅通过源码审查得到确认。

这个决定背后其实有一些理由：这样我对不同类型发现的信心水平就不会相互“模糊”。一个我亲眼看到让自己的硬件崩溃（或被利用……）的 bug，和一个我在上游源码树中推理出来的 bug，并不真的在同一水平上。把它们打包在一起可能会导致 Prusa 过度信任弱项、或不够信任强项，最坏情况下甚至全部丢弃，所以在它们之间划一条线非常合理。每项发现仍然附有完整的报告（我已经做了大量清理，但数量本身就给 Prusa 那边造成了痛苦——见下文），以及适用的 PoC 利用代码。既然 Prusa 现在已公开，我也将全部发布。

不过，让我们先讨论最严重的那一项，同时保持在高层次。完整报告在正式公告中：

PFB-008CVSS 8.1高已在硬件上复现攻击面：Connect 端点，受控或被 MITM，或 Connect 后端被攻陷 一条过长的 SEND_FILE_INFO 路径会溢出 Connect 任务的栈，并从受控或被拦截的 Connect 端点运行攻击者代码 Release 构建会丢弃 104 字节路径的断言，因此一个 463 字节的路径会让文件名写入溢出共享的 512 字节缓冲区，覆盖 planner 的 printer 指针，已在物理 MK4S 上确认。