Security readout for executives and security teams
Plain-English summary
MOOS-IvP deployments through 24.8.1 may trust unauthenticated shore-route announcements. An unauthorized publisher could redirect bridged vehicle communications to attacker-controlled infrastructure, exposing sensor and control information. The supplied record scores this critical, although it does not report service disruption or confirmed real-world exploitation.
Executive priority
Treat affected operational or autonomous-vehicle deployments as an urgent investigation and containment priority because compromised routing may disclose sensitive telemetry and control information. Immediately restrict bus publishers and unexpected shore connections. Coordinate patch decisions carefully because the cited correction remains an unmerged proposal.
Technical view
uFldNodeBroker does not validate the source of TRY_SHORE_HOST messages received on the vehicle bus. Any publisher able to submit those messages can enroll an attacker-controlled shore route and receive bridged traffic. This is classified as CWE-345, insufficient verification of data authenticity. A proposed fix exists, but the cited pull request is not merged.
Likely exposure
Prioritize MOOS-IvP installations through 24.8.1 that run uFldNodeBroker and permit untrusted or compromised publishers to reach the vehicle bus. Exposure depends on bus access controls and network segmentation. The affected-version metadata is internally unclear, so confirm exact applicability against current vendor guidance.
Exploitation context
The supplied CVSS 4.0 score is 9.3, reflecting network reachability, low complexity, no privileges, and high confidentiality and integrity impact. The source bundle marks KEV false and provides no evidence of active exploitation. Exploitation nevertheless requires the ability to publish a crafted shore-route message to the relevant vehicle bus.
Researcher notes
The cited NodeBroker.cpp location supports the message-handling sink, while Pull Request #124 and commit d66394f describe a proposed correction. The supplied affected-product metadata lists an anomalous version value of 0 with defaultStatus unaffected, conflicting with the narrative claim through 24.8.1. Validate version boundaries before declaring individual assets vulnerable.
Mitigation direction
- Inventory deployments running uFldNodeBroker through version 24.8.1.
- Restrict vehicle-bus publishing to authenticated, explicitly authorized components.
- Segment vehicle communications from untrusted networks and publishers.
- Monitor and block unexpected TRY_SHORE_HOST messages or unknown shore endpoints.
- Review vendor guidance and Pull Request #124 before applying the unmerged proposed fix.
Validation and detection
- Confirm installed MOOS-IvP versions and whether uFldNodeBroker is enabled.
- Map every principal and network path permitted to publish on the vehicle bus.
- Review logs and configuration for unexpected TRY_SHORE_HOST messages or shore routes.
- Verify approved shore endpoints against operational network inventories.
- After remediation, confirm unauthorized publishers cannot alter shore-route enrollment.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CWE-345: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Open ATT&CK lookupCVE-2026-85435 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- Critical
- CVSS
- 9.3 (4.0)
- Known Exploited
- No
- Published
Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
SSVC decision data
CVSS vector scores
2 official scoresWe collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N——VulnCheckCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N3.95.2VulnCheckVulnerability scoring details
Base CVSS 4.0 score
9.3CriticalVector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Base CVSS 3.1 score
9.1CriticalVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
- CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
- CVE publishedCVE Program
The CVE record was published.
- CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.
ADP provider summaries
Source materials
- CVE List V5 sourceCVE List V5
- Pull Request #124CVE reference, VulnCheck · issue-tracking, patch
- Proposed fix commit (pull request not merged)CVE reference, VulnCheck · patch
- https://github.com/moos-ivp/moos-ivpCVE reference, VulnCheck · product
- NodeBroker.cpp (verified sink)CVE reference, VulnCheck · technical-description
- VulnCheck Advisory: MOOS-IvP through 24.8.1 uFldNodeBroker Unauthenticated Shore Route EnrollmentCVE reference, VulnCheck · third-party-advisory
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
Insufficient Verification of Data Authenticity
Insufficient Verification of Data Authenticity represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.