搜「ROS 2」，Linux 内核的 AX.25 ROSE 协议排在机器人前面

一位接手机器人采购的首席信息安全官，把厂商名键入美国国家漏洞数据库（NVD）。2026 年 9 月 11 日，对 services.nvd.nist.gov/rest/json/cves/2.0 发出 keywordSearch=Unitree，返回 12 条记录，发布日期从 2022 年 8 月 5 日到 2026 年 8 月 27 日，CVSS v3.1 基础分从 4.7 到 9.6，其中五条的状态是 vulnStatus: Deferred。买方一杯咖啡还没凉，十二条就能读完。

还有第十三条，而那条查询不会返回它。CVE-2025-2894，2025 年 3 月 28 日发布，状态 Analyzed，CWE-912，CVSS v3.1 6.6 分，由 [email protected] 作为 Secondary 评分者给出，没有 NVD 的 Primary 评分。它的描述，全文如下：

"The Go1 also known as "The World's First Intelligence Bionic Quadruped Robot Companion of Consumer Level," contains an undocumented backdoor that can enable the manufacturer, and anyone in possession of the correct API key, complete remote control over the affected robotic device using the CloudSail remote access service."

大意是：Go1，又称「全球首款消费级智能仿生四足机器人伴侣」，含有一个未记录在案的后门，可让制造商以及任何持有正确 API 密钥的人，通过 CloudSail 远程访问服务对受影响的机器人设备取得完全的远程控制。

这段描述自始至终没有写出制造商的名字。它用「the Go1」和一句营销口号来指认这台机器。名字在记录里——在 CPE 适用性字段里出现了两次，cpe:2.3:o:unitree:go1_firmware 与 cpe:2.3:h:unitree:go1，五个参考链接里也有两个带着它。失效的是两者之间的关联：keywordSearch 匹配的是描述正文，不是适用性字段 [推断——由两次查询返回不同集合确立，不是出自 NVD 的文档]。这条记录归档正确、归属正确，而买方跑的那条检索看不见它。

这就是本文的论点，而它不是关于某一家厂商。服务机器人已公开的漏洞记录是真实的、可观的、第一手的。它归档在没有人会去键入的名字下面，按没有人会往下翻的顺序返回，于是采购人员的检索结果显得很薄——而这里的「薄」意味着记录没有被查过，不意味着机器是安全的。

两条否定结论框住了这个论点，而每一条都只与它的方法一样可靠。2026 年 9 月 11 日，keywordSearch=humanoid 返回 0 条——NVD，全库，不设日期筛选。它的边界是：这个词不在任何一条 NVD 描述里，而 2026 年 8 月 27 日发布的两条记录说的正是一台人形机器人，用的词是「G1 EDU」。

CISA 已知被利用漏洞目录（KEV），catalogVersion 2026.09.11，2026 年 9 月 12 日取回，共 1,709 条。把每一条的厂商、产品、名称和简述拼接起来做子串匹配，十三个厂商与组件名称各返回零条，robot 作为裸子串也返回零条。证明匹配器在工作的对照组是：ros 返回 499 条，每一处命中都落在「RouterOS」「Chromium」「Acrobat」里面。KEV 里没有条目，说的是「未被编目为已遭利用」——这是关于观测的陈述，不是关于机器的陈述。

人工整理的那个字段也有同样的病。2026 年 9 月 11 日，cpes/2.0?keywordSearch=unitree 返回 16 条字典条目，同一台机器有两种拼法：go_1_firmware 返回 1 条记录，go1_firmware 返回 3 条，后门记录排在第一。同一台机器，两个标识符，两个互不相交的集合，就在那个为了防止这种事而存在的字典里面。

关键词这条路

• keywordSearch=Unitree12 条记录
• 匹配描述正文CVE-2025-2894 不在其中

CPE 这条路

• cpeName=cpe:2.3:o:unitree:go1_firmware3 条记录——后门记录排第一
• cpeName=cpe:2.3:o:unitree:go_1_firmware1 条记录——同一台机器，第二种拼法
• cpes/2.0?keywordSearch=unitree16 条字典条目，两种拼法都在

• 买方跑的那条路：它读描述，而记录不在描述里
• 返回它的那条路：它读适用性字段，厂商名写在那里

更正，以及排在第一台机器人前面的十一条记录

本文的前提，我们写过一个错误的版本。我们自己的研究文件把「ROS 2」的记录写成了空集，本文的选题正是建立在那句话上。我们当时没有跑过这条查询。keywordSearch=ROS 2，2026 年 9 月 11 日，返回 52 条记录。

把 52 条描述逐条读完，得到 27 条真正的机器人记录、10 条属于 Linux 内核 ROSE/AX.25 这一族、15 条无关软件 [推断——我们的分类]。撞名不占多数；诚实的抱怨比这更尖锐。NVD 按最旧优先返回这个集合。读者看到的前十一条：CVE-2004-2390（Jabber 的 roster 处理）、两条内核 ROSE 记录、CVE-2009-3002（一个横跨六个套接字族的未初始化内存缺陷，AF_ROSE 是其中第五个）、再四条 ROSE、CVE-2012-4698（西门子 RuggedCom ROS）、CVE-2017-9347（Wireshark 的一个 ROS 解析器）和 CVE-2019-16236（Dino 的 roster 处理）。十一条里十一条，没有一条是机器人。第一条机器人记录是第十二条，CVE-2019-19625，关于 SROS 2。

失效之处是一个翻页深度，不是一个空集，而这对买方更糟，因为翻页深度看上去像一个答案。

标题说的是内核源码里的事实，不是拿巧合开玩笑。Linux v6.12 的 net/ax25/Kconfig，2026 年 9 月 11 日取回：

" tristate "Amateur Radio X.25 PLP (Rose)" depends on AX25"

ROSE 的配置项就放在 AX.25 目录里。52 条记录里有 10 条属于这一族；只有两条点名 af_rose.c 本身，其余落在路由、子程序和定时器路径上。

管用的查询是那个更老的名字。keywordSearch=Robot Operating System，2026 年 9 月 11 日，返回 43 条记录，43 条的描述里都有「robot」；其中 42 条是真正的 ROS 记录 [推断——我们的分类]。混进来的那条是 CVE-2023-35900，IBM Robotic Process Automation for Cloud Pak——连好的查询也有一次撞名，撞上的是 RPA。两个事件占了大头：2024 年 12 月 5 日与 6 日的 Nav2 导航批次 29 条，6 日 19 条、5 日 10 条；以及 2025 年 7 月 17 日的 5 条 ROS 工具代码执行记录。

然后是那个决定机群漏洞监测该怎么建的数字。两条查询共有 21 条记录，并集 74 条。「Robot Operating System」返回而「ROS 2」结果里没有的有 22 条——2020 年 6 月 24 日的三条 MiR100 与 MiR200 记录、2025 年 7 月的全部五条工具记录、2024 年 12 月那一批的一半。两条查询谁也不是谁的超集：只盯「ROS 2」的监测漏掉 74 条里的 22 条，只盯「Robot Operating System」的漏掉 31 条。

1. 第 1 至 11 条，按返回顺序

   1 · CVE-2004-2390Jabber 的 roster 处理

   2 · CVE-2005-3273Linux 内核 ROSE

   3 · CVE-2009-1265Linux 内核 ROSE

   4 · CVE-2009-3002横跨六个套接字族的未初始化内存；AF_ROSE 是第五个

   5 · CVE-2010-3310Linux 内核 ROSE，net/rose/af_rose.c

   6 · CVE-2011-1493Linux 内核 ROSE

   7 · CVE-2011-4913Linux 内核 ROSE

   8 · CVE-2011-4914Linux 内核 ROSE

   9 · CVE-2012-4698西门子 RuggedCom ROS，一个交换机操作系统

   10 · CVE-2017-9347Wireshark 的 ROS 解析器

   11 · CVE-2019-16236Dino 的 roster 处理

   十一条里十一条，没有一条是机器人。

2. 第 12 条

   12 · CVE-2019-19625SROS 2

   结果里第一条真正的机器人记录。

箭头是 NVD 自己的返回顺序，最旧优先——不设筛选，不设排序参数。

• 不是机器人：在 ROS 这三个字母上撞名
• 一条真正的机器人记录

• 只搜「ROS 2」 — 52 条记录 — keywordSearch=ROS 2
• 「Robot Operating System」 — 43 条记录 — keywordSearch=Robot Operating System，那个更老的名字
• 两个结果都有的 — 21 条记录 — 两条查询谁也不是谁的超集
• 两个 ROS 字符串合起来 — 74 条记录 — 机群漏洞监测必须覆盖的集合
• 只搜「Fast DDS」 — 24 条记录 — 组件
• 只搜「eProsima」 — 24 条记录 — 厂商——每个字符串都漏掉另一个找到的九条
• 两个中间件字符串合起来 — 33 条记录 — 一项依赖，两种写法，哪个都不完整
• 一对查询字符串合起来返回的
• 单个查询字符串各自返回的，以及两条 ROS 查询共有的 21 条

往下一层，一个没有人选过的名字

医院选的是机群管理系统。它不选中间件，而记录就在中间件里。

这条链条写在各项目自己的文件里，均于 2026 年 9 月 11 日取回。Open-RMF 的 README 称自己是 "a collection of packages, some of which have ROS 2 dependencies"（一组软件包，其中一部分依赖 ROS 2）；ros2/rmw 在 jazzy 分支上的构建系统带着一行注释 "# prefer FastDDS, otherwise first in alphabetical order"（优先 FastDDS，否则按字母序取第一个）；eProsima 的 Fast-DDS README 写道，ROS 把它 "as their default middleware for every ROS 2 long term (LTS) releases"（用作每一个 ROS 2 长期支持版本的默认中间件）。Open-RMF，以及在它之上的 RoMi-H，正是我们自己的 Crew 集成契约所面向的机群层。这些记录是我们自己要读的，不是一个案例研究。

2026 年 9 月 11 日，keywordSearch=Open-RMF 返回 0 条。说得准确一点：NVD 在这个名字下没有记录。本文若干记录的源头——GitHub 安全公告数据库——没有检索。

再往下一层，名字一分为二。keywordSearch=Fast DDS 返回 24 条，keywordSearch=eProsima 返回 24 条，都在 2026 年 9 月 11 日，并集 33 条——每条查询都恰好漏掉另一条找到的九条。剔除两条 Micro-XRCE-DDS Agent 记录，组件本身剩 31 条 [推断——我们的分类]。一个继承了这项依赖的运营方，得同时知道一家自己从未选过的厂商的两种写法，才能从任一侧看到它的三分之二。

这一层比这里的任何一家机器人厂商都做得好的一点，是把修复写在记录里。CVE-2026-22590，2026 年 9 月 9 日发布，状态 Awaiting Analysis，CVSS v3.1 9.1 分，由 [email protected] 作为 Secondary 评分者给出，没有 NVD 的 Primary 评分，是分片重组中的一处越界读。它的描述写明了去处：

"In a Discovery Server deployment, the resulting CacheChange_t can be relayed to other participants, meaning that a newly joining participant may receive leaked heap memory… Versions 2.6.12, 2.14.6, 3.2.4, 3.3.1, and 3.4.2 fix the issue."

大意是：在 Discovery Server 部署中，由此产生的 CacheChange_t 可能被转发给其他参与者，也就是说新加入的参与者可能收到泄漏的堆内存……2.6.12、2.14.6、3.2.4、3.3.1 与 3.4.2 版本修复了该问题。

它的同胞 CVE-2026-22591，同一天，Awaiting Analysis，v3.1 7.5 分，出在基于 SQL 的内容过滤器里，修复版本是 2.6.12、2.14.6、3.2.4 与 3.4.3——另一份清单，谁照着一份把两者合并的摘要打补丁，装上的就是错的构建。两条状态均于 2026 年 9 月 11 日确认，而 Awaiting Analysis 是会变的。同一集合里更早的 CVE-2025-67108，2025 年 12 月 23 日，状态 Modified，v3.1 10.0 分，关于票据吊销校验不当：它仅有的两个参考链接是一份 gist 和一行源码，所以准确的说法是，记录里没有写明修复版本。不是说修复不存在。

中间件的记录之所以写明修复版本，是因为它们源自 GitHub 安全公告，由切发布版本的那些人提交；机器人厂商的记录多半不写，是因为它们源自某国的 CERT 或独立研究者。一个组件在哪里维护，决定了它的记录会不会告诉你该装什么。

公平地读厂商

2026 年 8 月的两条人形机器人记录追溯到同一份披露：Olivier Laflamme 的《UniBLEed…》，2026 年 8 月 27 日，NVD 把它列为两条记录的参考。时间线是一次跑完了全程的协调披露。2026 年 4 月 29 日拿到机器；5 月 14 日第一个远程代码执行经厂商确认；6 月 25 日完整利用链确认，6 月 30 日前经厂商验证；7 月 1 日至 8 月 6 日之间，云端实施了账户与机器人的绑定检查；8 月 6 日支付赏金；8 月 18 日提交 CVE；2026 年 9 月 1 日发布 1.5.5.0 固件，披露者称它封堵了该利用链 [单一来源]。他补充说："I have not independently verified the fix."（我没有独立验证该修复。）他请读者把这项工作当作 "a point-in-time account of the platform as I found it during the research and disclosure period, not as a description of its current security posture"（对研究与披露期间我所见的平台的一份时点记述，而不是对其当前安全状况的描述），并写道 "Unitree moved quickly through triage, response, and remediation."（宇树在分诊、响应与修复上推进得很快。）

赏金在它自己的来源里就有出入：标题与导语说 6,700 美元，时间线在 2026 年 8 月 6 日下挂着一笔 5,000 美元，4,000 加 1,000，第三处又把这个拆分颠倒过来 [单一来源，内部自相矛盾]。两个数字，哪个都没有定论。

剩下的问题很窄，关乎索引而不是尽职。十二条记录里五条是 Deferred。没有一条带厂商安全公告链接；四条带的是产品页或商城页。而 security.unitree.com 返回 HTTP 200，页面标题是宇树安全应急响应中心——一个厂商安全响应中心，它发布的公告我们读不到，因为对普通抓取它只返回一个空壳。这是「无法核实」，也是对我们自己一句说得更满的话的诚实更正。

关于那台机器有一项发现不在任何 NVD 记录里。arXiv 2509.14139v3，Cybersecurity AI: Humanoid Robots as Attack Vectors，作者 Mayoral-Vilches、Makris 与 Finisterre，2025 年 9 月 17 日发表、9 月 23 日修订，报告该机器每 300 秒向两个 MQTT broker 外发遥测，操作者不会收到通知；论文 4.3 节把那批基础设施定位在中国司法辖区——这个司法辖区判断是他们提出的，我们也按他们的说法转述。同一篇摘要把这台机器 "otherwise sophisticated security architecture"（在其他方面颇为精密的安全架构）称为 "the most mature we have observed in commercial robotics"（我们在商用机器人领域观察到的最成熟的一个）。

科沃斯（Ecovacs）这一组：keywordSearch=Ecovacs 于 2026 年 9 月 11 日返回 16 条。CVE-2024-52331，v3.1 7.5 分，关于用一把确定性对称密钥解密固件更新。CVE-2024-52327，v3.1 6.5 分，缺陷组件是云服务，记录自己就这么写：它 "allows authenticated attackers to bypass the PIN entry required to access the live video feed"（允许已认证的攻击者绕过访问实时视频流所需的 PIN 输入）。CVE-2025-30199，2025 年 9 月 5 日，v3.1 7.2 分，关于不校验固件更新的基站，参考链接里有 CISA 的 ICSA-25-135-19 公告。然后是改变这组记录读法的事实：十六条里有六条带厂商安全公告链接，2026 年 9 月 12 日重新清点。我们取回的那一份，dsa20241217002，2026 年 9 月 11 日 HTTP 200，是一份注明日期、逐漏洞发布的公告，点名致谢发现者，并写明修复："Version 3.0.2 and later has addressed this issue."（3.0.2 及之后的版本已修复该问题。）这份证据否定了「消费级机器人厂商不发安全公告」的说法。

本文三家机器人厂商里，携带最高分记录的那台四足机器人是美国的。keywordSearch=Ghost Robotics 2026 年 9 月 11 日返回 6 条，不是我们预期的两条。CVE-2025-41108，2025 年 10 月 22 日，NVD 作为 Primary 给出 v3.1 9.8 分，另有 v4.0 9.2 分：一个通信协议，可能让攻击者发送指令，"impersonating the control station (tablet) and gaining unauthorised full control of the robot"（冒充控制站（平板）并取得对机器人的未授权完全控制）。CVE-2025-41109（4.6 / 8.7），关于三个 RJ45 接口和一个 USB Type-C 接口在连接时不做任何认证，收尾的那句话正是本文绕着打转的："Once inside, the attacker can monitor all its data, as the robot runs on ROS 2 without authentication by default."（一旦进入，攻击者可以监视它的全部数据，因为该机器人运行的 ROS 2 默认不开认证。）CVE-2025-41110（8.8 / 7.0）是移动应用安装包里的凭据。另外三条，2026 年 7 月 27 日发布，关于同一个应用，状态 Deferred，只带 v4.0 分数，来源是 INCIBE-CERT。

六条记录没有一条能确定补丁状态：每条只引用一份 INCIBE-CERT 通告，没有一条带厂商链接——这是关于参考清单的陈述，不是关于修复是否存在的陈述，而且我们没有访问该厂商的网站。这项发现是结构性的，不是国别性的：这些记录里有两条写明 ROS 2 默认不开认证地运行着，而 ROS 2 正是医院自己的机群链条所坐落的那一层，不论机身是谁造的。

两个分数、一个空框，以及该键入什么

同一个缺陷没有唯一的数字。CVE-2025-41109 在 NVD 作为 Primary 的 v3.1 评分是 4.6，向量 AV:P；在 INCIBE-CERT 的 v4.0 评分是 8.7，向量 AV:A。到了 CVE-2025-41110，两位评分者互换：NVD 的 8.8 选了 AV:A，INCIBE-CERT 的 7.0 选了 AV:P。版本更替不是原因：v4.0 的「物理」（Physical）就是 v3.1 的那句话，把「组件」换成了「系统」；「相邻」（Adjacent）加进了「近距离」和 NFC。两位评分者就同一台机器人产生了两次分歧，方向相反。

变的是作用域（Scope），v4.0 把它废除了："This property (formerly known as "Scope"), is captured by the separation of impacts to the vulnerable system and to subsequent systems."（这一属性（此前称为「Scope」）如今由「对易受攻击系统的影响」与「对后续系统的影响」的分离来体现。）CVE-2026-27510 一条记录里有三个分数——NVD 作为 Primary 的 v3.1 8.8，VulnCheck 的 v3.1 9.6，VulnCheck 的 v4.0 6.4，后者的向量写着 VC:N/VI:N/VA:N 与 SC:H/SI:H/SA:H：应用本身什么都不会发生，一切都发生在机器人上。对照 v4.0 的等级区间——中危 4.0 至 6.9，高危 7.0 至 8.9，严重 9.0 至 10.0——这一条记录是严重、高危还是中危，取决于工具读的是哪个分数。「先修严重级」这条策略，换一个扫描器就会返回另一台机器人。

于是说到那个框。CVSS v4.0 针对人身伤害定义了一项安全性（Safety）指标："Safety impact is applicable when it is predictable that an exploited vulnerability may result in injuries categorized as Marginal or worse using the IEC 61508 definitions outlined in the chart below"（当可以预见被利用的漏洞可能导致按下表所列 IEC 61508 定义归为「边缘」或更严重的伤害时，安全性影响适用）——那张表规范原文照录，从「灾难性」（多人丧生）到「可忽略」（至多轻伤）。IEC 61508 在这里只以 CVSS 转载的形式出现；我们没有读过该标准。规范把安全性排除在基础分之外——"Safety can only be associated with the Subsequent System impact set"（安全性只能与后续系统影响集关联）——放进了补充指标组与环境指标组，而给这些记录评分的评分者，没有一位填过。

我们从六条与机器人相关的查询响应里提取了每一个 CVSS v4.0 向量字符串，2026 年 9 月 11 日。三十二个向量。32 个全部带着 S:X，规范自己的表格把它定义为 "Not Defined (X) The metric has not been evaluated."（未定义（X）：该指标未经评估。）边界很窄：六条查询，只有 NVD，只有 v4.0 向量，只有一天，而只按 v3.1 评分的记录根本没有安全性指标可以留空。在这个边界之内，那个专为「一个缺陷可能伤到人」而设的字段，在我们取回的每一条关于会动的机器的记录上，都未经评估。

读一遍最后一列。七条记录里有五条由两位评分者对同一缺陷评分，其中前三条的第二个分数跨过了等级边界或者调换了攻击向量；后四行——其中两行是同一位评分者自己的两个分数——两个版本至多相差 0.6 分，落在同一个等级里。让这些数字动起来的不是版本更替。等级是 CVSS v4.0 自己的定性尺度——中危 4.0 至 6.9，高危 7.0 至 8.9，严重 9.0 至 10.0，2026 年 9 月 11 日读自 first.org——套用在两个版本的分数上，扫描器就是这么做的。上表每一个分数、向量和评分来源，都是 2026 年 9 月 11 日经 services.nvd.nist.gov 从记录本身读出，并于 9 月 12 日再读一次。这张表说的是一个缺陷如何被评分，不说它是否已修复：这里没有一列是补丁状态，也没有一列应当被当作补丁状态来读。

• 取回的 CVSS v4.0 向量 — 32 个向量 — 六条与机器人相关的查询响应里的每一个 v4.0 向量字符串
• 任一条评估了安全性（S） — 0 个向量 — 32 个全部带 S:X——“Not Defined (X) The metric has not been evaluated”
• 其中安全性指标带有任何已评估取值的
• 从六条查询提取的 CVSS v4.0 向量字符串

在这些证据上，买方该键入什么——每一个计数都跑于 2026 年 9 月 11 日：两个 ROS 名字都要，因为它们在 74 条里只共有 21 条；两个中间件名字都要，因为它们在 33 条里只共有 15 条；厂商名，然后是厂商的 CPE，因为 cpeName=cpe:2.3:o:unitree:go1_firmware:-:*:*:*:*:*:*:* 返回那条厂商名本身返回不了的后门记录。先到 cpes/2.0 里核对机器的拼法，因为这里面有一台是归在两种拼法下的。

然后读一读边界，因为这一条是我们自己的。语料是 NVD 的 cves/2.0 与 cpes/2.0，加上 CISA KEV 数据源，只有一天：十一条关键词查询，四条 cpeName= 查询，一条字典查询，十四次按标识符查询。

没有检索的——MITRE 的 CVE.org 记录库；GitHub 安全公告数据库，本文若干记录的源头；VulnCheck 的目录；JVN 与 JPCERT；INCIBE-CERT 的通告索引；NVD 参考清单之外的 ICS-CERT 公告；除我们取回的两份之外的所有厂商公告页；非英文记录；已披露而未发布的一切。最大的遗漏有名字：中国的 CNVD 与 CNNVD 完全没有检索，而这组记录里点名的三家厂商有两家是中国厂商。十一个厂商与组件名称里有九个是我们自己挑的，所以这不是对一家医院可能采购之物的穷尽扫描。

我们能回答的是一条查询返回什么、按什么顺序、在哪个名字下、漏了什么。我们不能说其中任何一项在一台运行中的机器上意味着什么，我们自己的机器也一样：这里没有任何东西在硬件上测过，我们自己的 Brain Kit 改装套件仍在研发中，上面没有一句话是对我们所造之物的安全性的宣称。

买方的检索只回来寥寥几行时，这项发现是关于索引的，不是关于机器人的。「薄」意味着没有被查过。从「没查过」到「查过」，代价是多一条查询字符串、一种 CPE 拼法和一个下午——而那个能说明其中任何一条会不会伤到人的字段，在我们读过的每一条记录上仍然是空的。