A critical flaw in MOOS-IvP's uFldShoreBroker (through version 24.8.1) lets unauthenticated attackers forge node ping messages and redirect bridged variables to addresses they control.
What Is It
CVE-2026-85434 is an insufficient verification of data authenticity issue (CWE-345) in the uFldShoreBroker component of MOOS-IvP. The broker fails to verify the authenticity of node pings before creating outbound bridge routes. An attacker can publish NODE_BROKER_PING messages containing crafted HostRecord data, causing the shore broker to establish bridge routes pointing at attacker-controlled addresses.
The CVE was published on 2026-09-03 and assigned by VulnCheck, which also published a coordinated advisory.
Why It Matters
The flaw carries a CVSS v3.1 base score of 9.1 (CRITICAL) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, and a CVSS v4.0 score of 9.3 (CRITICAL). Every exploitability factor is at its worst: the attack is reachable over the network, requires low complexity, needs no privileges, and needs no user interaction.
Impact is high for both confidentiality and integrity. Because the attacker controls where bridged variables are routed, they can siphon off data intended for legitimate nodes and inject or manipulate the variable flow between them. Availability is rated as not impacted.
MOOS-IvP is autonomy middleware, and uFldShoreBroker is the component that stitches field nodes to a shore-side controller; so the bridged variables at risk are the operational message flow of the deployment.
What's Vulnerable
- Vendor/product: moos-ivp
- Affected versions: all versions through 24.8.1 (
<= 24.8.1) - Component: uFldShoreBroker (
ivp/src/uFldShoreBroker/ShoreBroker.cpp)
No CPE entries were assigned in the NVD record at time of publication.
Patch Status
The NVD record is still in Received status, meaning NVD analysis is not yet complete and the entry carries no enrichment beyond what the assigning CNA supplied.
Upstream references include a specific commit (2f5224d) and pull request #123 in the moos-ivp repository, indicating a fix exists in source. Operators running 24.8.1 or earlier should track those upstream changes and treat the issue as actionable on its severity and exposure alone.