MOOS core-moos CVE-2026-85424

Exploitation requires only network reachability to the MOOSDB TCP listening port of a MOOS core-moos build at or before 10.4.0 running in its default configuration (no ServerKey / --moos_key set). No credentials, no user interaction, and no non-default feature toggle are needed - the missing authentication is the default state. The single limiting factor is network exposure: the attacker must be able to route to the MOOSDB port, so deployments that confine the bus to an isolated, firewalled, or loopback-only segment are not remotely exploitable from outside that segment. Once the patched build is in use, setting a non-empty ServerKey/--moos_key blocks unauthenticated clients, so patched-and-keyed instances are not exploitable in this manner.

This is a genuine high-priority issue for any exposed MOOSDB. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:H/VI:H/VA:H, score 9.3) is consistent with the description: network-reachable, no privileges, no user interaction, and confidentiality/integrity/availability all fully impacted (read all data, write all data, DB_CLEAR to reset). Real-world risk is tempered by exposure model rather than by exploit difficulty - MOOSDB is typically deployed on isolated vehicle/vessel networks or lab segments rather than the open Internet, so realistic exposure depends on whether the bus port is reachable by an attacker (adjacent network access, a compromised host on the segment, or a misconfigured route). No EPSS score, KEV listing, or public PoC was provided; there is no public exploit identified at time of analysis and no evidence of active exploitation, so the threat is currently latent rather than mass-exploited. Where the bus rides on a shared or reachable network, however, exploitation is trivial and unauthenticated, and any operator running a MOOS deployment should treat unrestricted DB_CLEAR access as urgent given it can halt or corrupt an entire autonomy stack in one message.

An attacker with access to the network segment carrying MOOS traffic (for example, a compromised sensor host or a laptop on an unsegmented vehicle LAN) opens a TCP connection to the MOOSDB port, sends the fixed protocol string, and completes the handshake under an arbitrary client name. They then subscribe to every variable to exfiltrate navigation, sensor, and command data, publish forged values to influence autonomy behavior, and issue DB_CLEAR to wipe all variables and mail queues, disrupting the mission. No credentials or user interaction are required, and the connection logic is a straightforward reimplementation of a normal MOOS client.