core-moos CVE-2026-85442

No special conditions are required - the vulnerable code path is reached before client authentication completes, meaning any attacker with TCP connectivity to the MOOSDB listening port can trigger the flaw against a default core-moos installation. Exploitation is limited in practice by the typical deployment of MOOSDB on private or vehicle-local networks not exposed to untrusted parties; if IP-level access to the MOOSDB port is already restricted to trusted hosts, exploitation requires the attacker to be on that trusted network segment.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) accurately characterizes this vulnerability: network-accessible, zero preconditions, pre-authentication, with full availability impact. The exploit path is mechanically trivial - send a single crafted packet before the auth handshake completes, and the server attempts a potentially multi-gigabyte heap allocation. No EPSS score was supplied, no active exploitation has been reported, and no public PoC has been identified at time of analysis; absent KEV listing, real-world exploitation risk must be judged from deployment context rather than NVD severity alone. The principal limiting factor is deployment footprint: MOOSDB is niche research and autonomous-vehicle infrastructure typically bound to private LANs or vehicle-local networks, meaning internet-exposed instances are uncommon. That said, even a mid-sized research institution running gniezno-style distributed autonomous vehicle trials should treat this as an urgent patch given the zero-complexity exploit path and potential for operational disruption to mission-critical vehicles. Where MOOSDB is exposed on an accessible network segment without IP filtering, the risk is high.

An attacker with TCP connectivity to the MOOSDB port sends a minimal wire-protocol packet in which the m_nMsgLen field is set to a value near the maximum signed integer (e.g., 2 GB or more). Before the server can challenge the client for authentication, OnBytesWritten() reads this field and passes it to InflateTo(), which calls new unsigned char[~2GB], rapidly exhausting heap memory. Repeating this across multiple connections in parallel causes the MOOSDB process to crash or become unresponsive, denying service to all legitimate clients including autonomous vehicle control software.