MOOS core-moos EUVD-2026-70812

Requires network reachability to the optional MOOSDB HTTP server port, which must be enabled in the deployment (the HTTP status server is not always started). In vulnerable versions ≤10.4.0 no further prerequisite exists - no credentials, no user interaction, and the write 'poke' path is active by default. Exploitation is limited only by whether the HTTP server is running and whether the port is reachable from the attacker's network position; MOOSDB deployments on isolated vehicle/control networks reduce practical exposure. Note the fix inverts this: post-patch, WEBSERVERALLOWPOKE must be explicitly set true for the write path to exist at all.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, score 9.3) reflects a network-reachable, unauthenticated write against default configurations, which the source diff corroborates: pre-patch there was no gate at all on the HTTP poke path. The most defensible impact is on integrity and availability - an attacker can inject actuator/override commands or corrupt mission variables, potentially hijacking or stalling an autonomous platform - while confidentiality impact from the write vector itself is modest (values are echoed back on the status page), so VC:H is arguably overstated. There is no EPSS or KEV signal supplied and no public PoC noted, so exploitation is currently theoretical rather than observed; however, the trivial exploit complexity and safety-relevant impact mean any operator running MOOSDB with the HTTP server exposed should treat this as urgent and patch or firewall the port promptly. Real-world exposure is bounded by the fact that MOOSDB is typically deployed on isolated vehicle/lab networks, which reduces internet-facing reachability even though on-network exploitation is trivial.

An attacker with network access to the vehicle/lab segment scans for the MOOSDB HTTP server port, then sends an HTTP request naming a control variable (e.g. an actuator or override command) with an attacker-chosen value. The MOOSDB accepts the write without any credential, letting the attacker steer or disrupt the autonomous platform; no public PoC is noted, but the diff shows the write path was reachable by anyone able to reach the port.