core-moos CVE-2026-85432

The attacker must have completed the MOOSDB TCP handshake with a valid MOOS client name, meaning they need network reachability to the MOOSDB port and the ability to register as any MOOS client identity (no specific credential beyond connection establishment is required by default). No non-default configuration is needed - all MOOSDB instances through 10.4.0 are vulnerable as shipped because source-field overriding was never implemented in the message-processing path. Exploitation is bounded by the attacker's ability to reach the MOOSDB network port: deployments binding only to loopback or isolated robotics LANs limit exposure to local or insider threats, while deployments with MOOSDB accessible on shared or routable interfaces expand the attacker pool to any network-adjacent party who can complete a MOOS handshake.

The provided CVSS 4.0 vector assigns PR:N (no privileges required), which directly contradicts the CVE description's explicit qualifier 'authenticated attackers' - the attacker must first complete a MOOS client handshake, placing true privilege requirements at PR:L. This discrepancy materially overstates the attack surface by implying unauthenticated remote exploitation when a connection credential is actually required. The integrity impact (VI:H) is well-founded: successful exploitation allows full source-attribution spoofing across the broker, enabling a connected attacker to corrupt the data provenance model that MOOS applications depend upon for mission-critical decision-making. The availability impact (VA:L/SA:L) reflects the subscription-cancellation vector, which can disrupt specific data feeds without a full denial of service. EPSS data is absent from the input, and no KEV listing or public exploit code has been identified at time of analysis. Practical risk is strongly bounded by MOOSDB's network exposure: many deployments bind to loopback or isolated research LANs, restricting the attacker pool to insiders or users who can already establish a MOOS client connection. Nevertheless, even a mid-sized autonomous systems operator or research fleet running MOOSDB in a shared-network environment like tczew should treat this as a priority remediation, since integrity failures in message attribution could cause incorrect variable states or command attributions to propagate to vehicle control processes. The patch is available at commit 26308f0e but no tagged release version has been confirmed.

An attacker with an established MOOS client connection crafts a serialized MOOS notification packet in which the m_sSrc field is set to the registered name of a victim process such as pHelmIvP or iGPS. When submitted to MOOSDB, the broker attributes the variable write to the spoofed identity and may honor subscription cancellation requests appearing to originate from the victim, silently severing the victim's data feeds. No public exploit code has been identified, but the PR diff fully documents the vulnerable code path, making construction of a proof-of-concept trivial for any developer familiar with the MOOS serialization format.