Severity Daily

IT and AI security incidents, checked against the primary source

Tag: MOOS-IvP

  • MOOS marine autonomy middleware takes 33 CVEs at once, and the fix for the unauthenticated bus is an unmerged pull request

    MOOS marine autonomy middleware takes 33 CVEs at once, and the fix for the unauthenticated bus is an unmerged pull request

    Thirty-three CVE records landed on the MOOS robotics middleware family on September 3, 2026, in one contiguous block running from CVE-2026-85424 to CVE-2026-85456. All were assigned by VulnCheck as CNA and credited to a single researcher, Vlatko Kosturjak. They cover four separate repositories, and between them they describe a message bus with no authentication, a packet parser that trusts attacker-supplied lengths before any handshake, and several applications that pass bus contents into a shell. The proposed fix for the first of those exists. It is a pull request the researcher opened himself on September 2, and as of this writing no maintainer has commented on it.

    What happened

    MOOS is a publish/subscribe middleware. The themoos/core-moos repository describes it as “A very light weight, easy to use middleware. You will need core-moos above all other components.” The autonomy layer built on it, MOOS-IvP, is described by its own repository as “a set of modules for providing autonomy on robotic platforms, in particular autonomous marine vehicles.” It has a long academic trail behind it in unmanned marine vehicle research. The affected version strings across the batch are core-moos through 10.4.0, essential-moos through 10.0.1, MOOS-IvP through 24.8.1, and ui-moos through commit 50b9c6c.

    The anchor record is CVE-2026-85424, scored 9.8 under CVSS v3.1 in the NVD record and 9.3 under CVSS v4.0 on VulnCheck’s own advisory page — the same assigner, two scoring frameworks, not a dispute. VulnCheck’s text: attackers can “bypass the compile-time protocol string check and connect with arbitrary client names to execute privileged operations including DB_CLEAR which resets all variables and clears client mail queues.” The NVD description is blunter: core-moos “lacks authentication in the wire protocol, allowing unauthenticated clients to connect with full publish, subscribe, and database clear privileges.” CWE-306.

    The rest of the batch falls into recognizable groups.

    Pre-authentication memory corruption. CVE-2026-85440 is a heap overflow in MOOSCommPkt packet handling at 9.8, reachable before any client identifies itself. CVE-2026-85455, at 8.2, is a buffer over-read triggered by a four-byte packet — open a TCP connection to the MOOSDB port, send four bytes, read memory. CVE-2026-85441 and CVE-2026-85442 cover unvalidated serialized string lengths and unbounded packet-length allocation, both 7.5.

    Bus contents reaching a shell. CVE-2026-85425 (9.8) is remote code execution in iSay, which passes the text of the SAY_MOOS variable to shell commands unsanitized. CVE-2026-85426 (9.8) builds shell commands in uMemWatch out of client names the attacker chooses. CVE-2026-85439 (7.8) is the same class in alogsplit. CVE-2026-85427 (8.1) lets an unauthenticated attacker run an arbitrary program through pAntler via a MISSION_FILE message.

    Trusting the message instead of the connection. CVE-2026-85433 (9.8) lets any publisher reconfigure pShare network routes and listeners through unauthorized PSHARE_CMD messages. CVE-2026-85430 (9.1) has pShare accepting UDP datagrams from any source and republishing them onto the bus. CVE-2026-85434 (9.1) and CVE-2026-85435 (9.1) are the shore-side and vehicle-side halves of the same problem in uFldShoreBroker and uFldNodeBroker: node pings and TRY_SHORE_HOST messages are acted on without verifying who sent them. CVE-2026-85429 (7.5) has uFldNodeComms taking the source node identity from the message body rather than the connection.

    The autonomy decision path itself. CVE-2026-85437 and CVE-2026-85438, both 9.8, are buffer overflows in the IvP function string decoders. CVE-2026-85438 names the mechanism: StringToIvPFunction() uses attacker-supplied dimension, piece, and degree counts without validation. Those decoders parse the objective functions that the behavior engine uses to pick a course of action.

    Two more deserve a line. CVE-2026-85451 (7.1) covers SuicidalSleeper, which authorizes multicast termination commands with a hard-coded passphrase; any multicast-reachable peer can enumerate MOOS processes and shut them down. CVE-2026-85449 (7.5) lets an attacker exhaust pMarineViewer‘s memory with unbounded distinct node names in NODE_REPORT messages and, in NVD’s phrasing, “stall the operator display without authentication.”

    Pull request 84 against themoos/core-moos is titled “Add an optional shared key for MOOSDB admission.” It was opened on September 2, 2026 by the GitHub account kost, carries a single commit, and adds a shared key checked during the client handshake — configurable through a ServerKey mission-file entry or a --moos_key flag, defaulting to an empty key so existing deployments keep working, and compared in constant time. It reuses an unused auxiliary field in the name message so the wire format does not change. It is open. It has no reviews, no assignees, no labels, and no maintainer comments.

    Why it matters

    Thirty-three records is a number that invites the wrong reading. This is not thirty-three independent mistakes. It is closer to one architectural decision — a bus that assumes everything on it is trusted — enumerated thirty-three ways, plus a genuine second cluster of memory-safety bugs in the parsers that speak to that bus. Robotics middleware has been here before: ROS 1 shipped for years on the same assumption, and the industry’s answer was not to patch the bus but to build a successor with authentication in it.

    That history is why the shape of the disclosure matters more than the count. When a researcher enumerates a design assumption into three dozen CVE records, each record acquires a score, and the scores travel. Twelve of these carry critical severity. Every one of them uses “through <version>” phrasing with no fixed version named, which means each record stays open-ended until someone ships a release and updates it. A vulnerability management program that ingests this batch will see twelve criticals against software with no patched version, and there is no vendor PSIRT to call.

    The unmerged pull request is the part that will decide how this goes. The researcher did the unusual and generous thing: rather than publishing a finding and leaving the maintainers to design a fix, he wrote a backward-compatible one that does not break the wire format and defaults to off. That design choice is what makes it mergeable and also what limits it — an optional key that defaults to empty fixes nothing for anyone who does not set it. The value is that it gives operators a switch to throw. Right now they do not have one, and the pull request that would give them one has been sitting unreviewed for two days across a disclosure.

    There is a fair reading in which none of this is urgent. MOOS deployments are typically on a vehicle network or a research LAN, not the public internet, and the pre-authentication memory bugs need reachability to the MOOSDB port. That reading is exactly what the design assumed, and it holds until a vehicle network touches a shore network, a topside laptop is on both, or a bridge like pShare is configured to accept UDP — which CVE-2026-85430 says it does, from any source.

    What to do

    No fixed release exists for any of the 33 records. The available actions are network and configuration ones.

    • Treat the MOOSDB port as an administrative interface. It has no authentication, by design and now by CVE. Bind it to a loopback or vehicle-only interface and put an explicit deny in front of it from any network a person can reach.
    • Audit pShare and pMOOSBridge configurations for UDP listeners. CVE-2026-85430 and CVE-2026-85431 both turn on a listener accepting datagrams from any source; if you use one, source-restrict it at the firewall.
    • If you run the optional MOOSDB HTTP server, turn it off. Three separate records cover it — an authentication bypass allowing unauthenticated variable writes (CVE-2026-85428, 9.8), unbounded connections and threads (CVE-2026-85450, 7.5), and unescaped database contents rendered into the page (CVE-2026-85453, 6.1).
    • Review whether iSay, uMemWatch, or alogsplit are running in any configuration where a bus writer is not fully trusted. All three take bus content into a shell.
    • If you maintain a MOOS fork, pull request 84 is the change to evaluate. Setting a non-empty ServerKey is the only admission control on offer.

    Sourcing note

    Checked: NVD records for CVE-2026-85424 through CVE-2026-85456, retrieved from the NIST CVE API on September 4, 2026, with all descriptions and scores taken from those records; VulnCheck’s own advisory page for CVE-2026-85424, which supplied the researcher credit, the CVSS v4.0 score, and the DB_CLEAR language; the themoos/core-moos repository and pull request 84 on GitHub; the themoos organization page for the repository descriptions.

    Could not reach: moos-ivp.org, the project’s distribution site, which did not complete a TLS certificate check from this environment. That is a first-hand observation from one automated fetch and is not a claim that the site is broken for browsers.

    Unresolved: whether the maintainers were notified before publication and on what date — VulnCheck’s advisory states a disclosure date of September 3, 2026 but does not describe the coordination timeline or a vendor response. Whether pull request 84 will be merged, and whether a release will follow that lets the records name a fixed version. This is a single-researcher, single-CNA disclosure; no second party has independently confirmed the findings, and no exploitation has been reported.