Searching for "ROS 2" finds the Linux AX.25 ROSE protocol

A CISO handed a robot procurement types the vendor's name into the US National Vulnerability Database. On 11 September 2026, keywordSearch=Unitree against services.nvd.nist.gov/rest/json/cves/2.0 returned 12 records, published between 5 August 2022 and 27 August 2026, CVSS v3.1 base scores from 4.7 to 9.6, five at vulnStatus: Deferred. A buyer can read all twelve before a coffee goes cold.

There is a thirteenth record, and that query does not return it. CVE-2025-2894, published 28 March 2025, Analyzed, CWE-912, CVSS v3.1 6.6 scored by [email protected] as Secondary, no NVD Primary. Its description, whole:

"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."

The description never names the manufacturer. It identifies the machine as "the Go1" and by a marketing slogan. The name is in the record — twice in the CPE applicability field, as cpe:2.3:o:unitree:go1_firmware and cpe:2.3:h:unitree:go1, and in two of the five reference URLs. What fails is the join: keywordSearch matches description prose, not the applicability field [inference — established by two queries returning different sets, not by NVD documentation]. The record is filed and attributed correctly, and the search a buyer runs is blind to it.

That is the argument, and it is not about one vendor. The published vulnerability record of service robots is real, substantial and primary. It is catalogued under names nobody types and returned in an order nobody scrolls past, so a procurement officer's search comes back thin — and thin here means the record is unexamined, not that the machine is secure.

Two negatives frame it, and each is only as good as its method. keywordSearch=humanoid returned 0 records on 11 September 2026 — NVD, whole database, no date filter. The bound: the word is not in an NVD description, and two records published 27 August 2026 are on a humanoid and say "G1 EDU" instead.

CISA's Known Exploited Vulnerabilities catalogue, catalogVersion 2026.09.11, fetched 12 September 2026, holds 1,709 entries. Concatenating vendor, product, name and short description across all of them and substring-matching returns zero for each of thirteen vendor and component terms, and zero for robot as a bare substring. The control that shows the matcher works: ros returns 499, every hit inside "RouterOS", "Chromium", "Acrobat". An absent KEV entry says not catalogued as exploited — a statement about observation, not about the machine.

The curated field has the same disease. cpes/2.0?keywordSearch=unitree returned 16 dictionary entries on 11 September 2026, one machine spelled two ways: go_1_firmware returns 1 record and go1_firmware returns 3, the backdoor record first. Same machine, two identifiers, disjoint sets, inside the dictionary that exists to prevent that.

Keyword route

• keywordSearch=Unitree12 records
• Matches description proseCVE-2025-2894 is not among them

CPE route

• cpeName=cpe:2.3:o:unitree:go1_firmware3 records — the backdoor record first
• cpeName=cpe:2.3:o:unitree:go_1_firmware1 record — the same machine, second spelling
• cpes/2.0?keywordSearch=unitree16 dictionary entries, carrying both spellings

• The route a buyer runs: it reads the description, and the record is not in it
• The route that returns it: it reads the applicability field, where the vendor is named

The correction, and the eleven records before the first robot

We wrote a version of this article's premise that was false. Our own research file recorded the record for "ROS 2" as an empty one, and this article's commission was written on that sentence. We had not run the query. keywordSearch=ROS 2, 11 September 2026, returns 52 records.

Reading all 52 descriptions gives 27 genuine robotics records, 10 in the Linux kernel's ROSE/AX.25 family and 15 unrelated software [inference — our classification]. Collisions are not the majority; the honest complaint is sharper. NVD returns the set oldest-first. The first eleven a reader sees: CVE-2004-2390 (Jabber roster handling), two kernel ROSE records, CVE-2009-3002 (an uninitialised-memory bug across six socket families, of which AF_ROSE is the fifth), four more ROSE, CVE-2012-4698 (Siemens RuggedCom ROS), CVE-2017-9347 (a Wireshark ROS dissector) and CVE-2019-16236 (Dino roster handling). Eleven for eleven, none of them robotics. The first robotics record is the twelfth, CVE-2019-19625, on SROS 2.

The failure is a scroll depth, not an empty set, and that is worse for the buyer, because a scroll depth looks like an answer.

The title is a fact about kernel source, not a joke about a coincidence. net/ax25/Kconfig in Linux v6.12, fetched 11 September 2026:

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

The ROSE configuration lives inside the AX.25 directory. Ten of the 52 records are in that family; only two name af_rose.c itself, the rest route, subroutine and timer paths.

The query that works is the older name. keywordSearch=Robot Operating System, 11 September 2026, returns 43 records, all 43 with "robot" in the description; 42 are genuine ROS records [inference — our classification]. The intruder is CVE-2023-35900, IBM Robotic Process Automation for Cloud Pak — even the good query has one collision, and it is RPA. Two events dominate: 29 records in the Nav2 navigation batch of 5 and 6 December 2024, 19 on the sixth and 10 on the fifth, and 5 ROS tool code-execution records of 17 July 2025.

Then the number that decides how a fleet watch gets built. The two queries share 21 records; their union is 74. Twenty-two that "Robot Operating System" returns — the three MiR100 and MiR200 records of 24 June 2020, all five July 2025 tool records, half the December 2024 batch — are absent from the "ROS 2" result. Neither query is a superset of the other: a watch on "ROS 2" alone misses 22 of the 74, one on "Robot Operating System" alone misses 31.

1. Records 1–11, as returned

   1 · CVE-2004-2390Jabber roster handling

   2 · CVE-2005-3273Linux kernel ROSE

   3 · CVE-2009-1265Linux kernel ROSE

   4 · CVE-2009-3002uninitialised memory across six socket families; AF_ROSE is the fifth

   5 · CVE-2010-3310Linux kernel ROSE, net/rose/af_rose.c

   6 · CVE-2011-1493Linux kernel ROSE

   7 · CVE-2011-4913Linux kernel ROSE

   8 · CVE-2011-4914Linux kernel ROSE

   9 · CVE-2012-4698Siemens RuggedCom ROS, a switch operating system

   10 · CVE-2017-9347Wireshark ROS dissector

   11 · CVE-2019-16236Dino roster handling

   Eleven for eleven, none of them robotics.

2. Record 12

   12 · CVE-2019-19625SROS 2

   The first genuine robotics record in the result.

The arrow is NVD's own return order, oldest first — no filter, no sort parameter.

• Not robotics: a name collision on the three letters ROS
• A genuine robotics record

• “ROS 2” alone — 52 records — keywordSearch=ROS 2
• “Robot Operating System” — 43 records — keywordSearch=Robot Operating System, the older name
• In both results — 21 records — neither query is a superset of the other
• Both ROS strings together — 74 records — the set a fleet watch has to cover
• “Fast DDS” alone — 24 records — the component
• “eProsima” alone — 24 records — the vendor — each string misses nine the other finds
• Both middleware strings — 33 records — one dependency, two spellings, neither complete
• What a pair of query strings returns together
• What one query string returns on its own, and the 21 records the two ROS queries share

One layer down, under a name nobody chose

A hospital chooses a fleet manager. It does not choose a middleware, and the middleware is where the records are.

The chain is in the projects' own files, all fetched 11 September 2026. Open-RMF's README calls it "a collection of packages, some of which have ROS 2 dependencies"; the ros2/rmw build system on branch jazzy carries the comment "# prefer FastDDS, otherwise first in alphabetical order"; eProsima's Fast-DDS README describes ROS using it "as their default middleware for every ROS 2 long term (LTS) releases". Open-RMF, and RoMi-H above it, is the fleet layer our own Crew integration contract is written against. These records are ours to read, not a case study.

keywordSearch=Open-RMF returned 0 records on 11 September 2026. Stated properly: NVD holds no record under that name. The GitHub Security Advisory database, where several records in this article originate, was not searched.

One layer down, the name splits in two. keywordSearch=Fast DDS returns 24 records and keywordSearch=eProsima returns 24, both on 11 September 2026, and their union is 33 — each query missing exactly nine the other finds. Excluding the two Micro-XRCE-DDS Agent records leaves 31 in the component proper [inference — our classification]. An operator who inherited this dependency has to know both spellings of a vendor they never selected to see two-thirds of it from either side.

What that layer does better than any robot vendor here is state its fixes in the record. CVE-2026-22590, published 9 September 2026, Awaiting Analysis, CVSS v3.1 9.1 scored by [email protected] as Secondary with no NVD Primary, is an out-of-bounds read in fragment reassembly. Its description says where it goes:

"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."

Its sibling CVE-2026-22591, same day, Awaiting Analysis, v3.1 7.5, is in the SQL-based content filter, and its fixed versions are 2.6.12, 2.14.6, 3.2.4 and 3.4.3 — a different list, and anyone patching from a summary that merges the two ships the wrong build. Both statuses were confirmed on 11 September 2026, and Awaiting Analysis moves. Older in the same set, CVE-2025-67108, 23 December 2025, Modified, v3.1 10.0, on improper validation of ticket revocation: its only two references are a gist and a source line, so the accurate statement is that no fixed version is stated in the record. Not that none exists.

The middleware records name their fixed releases because they originate as GitHub Security Advisories, filed by the people who cut the releases; the robot vendors' records mostly do not, because they originate with a national CERT or an independent researcher. Where a component is maintained decides whether its record tells you what to install.

The vendors, read fairly

The August 2026 humanoid records trace to one disclosure: Olivier Laflamme, "UniBLEed…", 27 August 2026, listed by NVD as a reference for both. The timeline is a coordinated disclosure that ran. Machine in hand 29 April 2026; a first remote code execution validated by the vendor on 14 May; a full chain confirmed 25 June and validated by 30 June; a cloud-side account-to-robot binding check implemented between 1 July and 6 August; a bounty paid 6 August; CVEs submitted 18 August; firmware 1.5.5.0 released 1 September 2026, which the discloser reports blocks the chain [single source]. He adds: "I have not independently verified the fix." He asks that the work be read as "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", and writes that "Unitree moved quickly through triage, response, and remediation."

The bounty is contested inside its own source: the headline and lede say $6,700, the timeline attaches a $5,000 payment to 6 August 2026, $4,000 plus $1,000, and a third passage reverses the split [single source, internally inconsistent]. Both figures, neither of them settled.

What remains is narrow, and about indexing rather than diligence. Five of the twelve records are Deferred. None carries a vendor security-advisory URL; four carry product or shop pages. And security.unitree.com returns HTTP 200 with the title 宇树安全应急响应中心, a vendor security response centre whose advisory output we could not read, because the site returns a shell to a plain fetch. That is a could-not-verify, and the honest correction to a sentence of our own that said more.

One finding about that machine is in no NVD record at all. arXiv 2509.14139v3, Cybersecurity AI: Humanoid Robots as Attack Vectors, by Mayoral-Vilches, Makris and Finisterre, 17 September 2025 and revised 23 September, reports telemetry leaving it to two MQTT brokers every 300 seconds without operator notice; its section 4.3 places that infrastructure in Chinese jurisdiction — the paper's assertion, carried as the paper's. The same abstract calls the machine's "otherwise sophisticated security architecture" "the most mature we have observed in commercial robotics".

keywordSearch=Ecovacs returned 16 records on 11 September 2026. CVE-2024-52331, v3.1 7.5, on a deterministic symmetric key for decrypting firmware updates. CVE-2024-52327, v3.1 6.5, where the defective component is the cloud service and the record says so: it "allows authenticated attackers to bypass the PIN entry required to access the live video feed". CVE-2025-30199, 5 September 2025, v3.1 7.2, on base stations that do not validate firmware updates, with CISA advisory ICSA-25-135-19 in its references. Then the fact that changes how the set reads: six of the sixteen carry a vendor security-advisory URL, re-counted 12 September 2026. The one we fetched, dsa20241217002, HTTP 200 on 11 September 2026, is a dated per-vulnerability advisory that credits the finders by name and states the fix: "Version 3.0.2 and later has addressed this issue." This evidence refuses the claim that consumer-robot vendors publish no advisories.

The quadruped carrying the highest-scored record of the three robot vendors here is American. keywordSearch=Ghost Robotics returned 6 records on 11 September 2026, not the two we expected. CVE-2025-41108, 22 October 2025, v3.1 9.8 as NVD Primary and v4.0 9.2: a communication protocol that could let an attacker send commands "impersonating the control station (tablet) and gaining unauthorised full control of the robot". CVE-2025-41109 (4.6 / 8.7), on three RJ45 connectors and a USB Type-C port with no authentication on connection, ends on the sentence this article circles: "Once inside, the attacker can monitor all its data, as the robot runs on ROS 2 without authentication by default." CVE-2025-41110 (8.8 / 7.0) is credentials in the mobile app package. Three more, published 27 July 2026 on that app, are Deferred, carry only a v4.0 score and are sourced to INCIBE-CERT.

Patch status is not establishable for any of the six: each references exactly one INCIBE-CERT notice and none carries a vendor URL — a statement about reference lists, not about whether a fix exists, and we did not visit the vendor's site. The finding is structural, not national: two of these records name ROS 2 running without authentication by default, and ROS 2 is the layer the hospital's own fleet chain sits on, whoever built the body.

Two scores, one empty box, and what to type

The same flaw does not have one number. CVE-2025-41109 is v3.1 4.6 with AV:P from NVD as Primary, and v4.0 8.7 with AV:A from INCIBE-CERT. On CVE-2025-41110 the two assessors swap: NVD chose AV:A for its 8.8, INCIBE-CERT AV:P for its 7.0. The version change is not the cause: v4.0's Physical is v3.1's sentence with "system" for "component", and Adjacent gained "proximity" and NFC. Two assessors are disagreeing about one robot, twice, in opposite directions.

What did change is Scope, which v4.0 retires: "This property (formerly known as "Scope"), is captured by the separation of impacts to the vulnerable system and to subsequent systems." CVE-2026-27510 carries three scores in one record — NVD v3.1 8.8 as Primary, VulnCheck v3.1 9.6, VulnCheck v4.0 6.4, whose vector reads VC:N/VI:N/VA:N and SC:H/SI:H/SA:H: nothing happens to the app, everything happens to the robot. Against the v4.0 bands — Medium 4.0 to 6.9, High 7.0 to 8.9, Critical 9.0 to 10.0 — that one record is Critical, High or Medium depending which score a tool reads. A policy of patching criticals first returns a different robot depending on the scanner.

Which brings up the box. CVSS v4.0 defines a Safety metric against injury: "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" — a chart the specification reproduces, running from Catastrophic, multiple loss of life, to Negligible, minor injuries at worst. IEC 61508 appears here only as CVSS reproduces it; we have not read the standard. The specification keeps Safety out of the Base score — "Safety can only be associated with the Subsequent System impact set" — and puts it in the Supplemental and Environmental groups, which not one of the assessors scoring these records populated.

We extracted every CVSS v4.0 vector string from the six robot-related query responses on 11 September 2026. Thirty-two vectors. All 32 carry S:X, which the specification's own table defines as "Not Defined (X) The metric has not been evaluated." The bound is narrow: six queries, NVD only, v4.0 vectors only, one day, and records scored only under v3.1 have no Safety metric to leave blank. Within it, the one field built to say that a flaw could hurt a person is unevaluated on every record we pulled about a machine that moves.

Read down the last column. Two assessors score the same flaw on five of these seven records, and on the first three of those the second score crosses a band boundary or swaps the access vector; on the last four rows — two of which carry one assessor's own two scores — the versions differ by at most six-tenths of a point and stay inside a single band. The version change is not what moves these numbers. Bands are CVSS v4.0's own qualitative scale — Medium 4.0 to 6.9, High 7.0 to 8.9, Critical 9.0 to 10.0, read from first.org on 11 September 2026 — applied to both versions' scores, which is what a scanner does. Every score, vector and scoring source above was read from the record itself through services.nvd.nist.gov, on 11 September 2026 and again on 12 September. The table says how one flaw is scored and nothing about whether it is fixed: no column here carries patch status, and none should be read as one.

• CVSS v4.0 vectors pulled — 32 vectors — every v4.0 vector string in the six robot-related query responses
• Safety (S) evaluated on any — 0 vectors — all 32 carry S:X — “Not Defined (X) The metric has not been evaluated”
• Those carrying any evaluated value in the Safety metric
• CVSS v4.0 vector strings extracted from the six queries

What a buyer should type, on this evidence, with every count run on 11 September 2026: both ROS names, because they share only 21 of 74 records; both middleware names, because they share only 15 of 33; the vendor's name, and then the vendor's CPE, because cpeName=cpe:2.3:o:unitree:go1_firmware:-:*:*:*:*:*:*:* returns the backdoor record that the vendor's own name does not. Check the machine's spelling in cpes/2.0 first, because one of these is filed under two.

Then read the bound, because this one is ours. The corpus was NVD's cves/2.0 and cpes/2.0 plus the CISA KEV feed, on one day: eleven keyword queries, four cpeName= queries, one dictionary query, fourteen lookups by identifier.

Not searched — MITRE's CVE.org record store; the GitHub Security Advisory database, where several of these records originate; VulnCheck's catalogue; JVN and JPCERT; INCIBE-CERT's notice index; ICS-CERT advisories beyond those in NVD reference lists; every vendor advisory page but the two we fetched; non-English records; anything disclosed and unpublished. The largest omission has a name: China's CNVD and CNNVD were not searched at all, for a set in which two of the three named vendors are Chinese. Nine of the eleven vendor and component names were chosen by us, so this is not an exhaustive sweep of what a hospital might buy.

We can answer what a query returns, in what order, under which name, and with what left out. We cannot say what any of it means on a running machine, ours included: nothing here was measured on hardware, our own Brain Kit retrofit is in development, and no sentence above is a claim about the security of anything we build.

When a buyer's search comes back with a handful of rows, the finding is about the index, not the robot. Thin means unexamined. Getting to examined costs a second query string, a CPE spelling and an afternoon — and the field that would say whether any of it could injure someone is still empty on every record we read.