OpenDDS CVE-2026-52486

Exploitation requires local access to a host running OpenDDS 3.33.x and a low-privileged operating system account (PR:L per CVSS vector AV:L/PR:L). DDS Security must be enabled and the signed document verification path must be reachable - this typically requires a deployment where signed governance or permissions documents are actively exchanged between DDS participants during security handshake. The SSVC designation of automatable: no confirms that the attack requires deliberate, targeted interaction rather than automated scanning. Exploitation is not possible over the network from this specific flaw (AV:L). Limiting factors include: the requirement for a local OS account; DDS Security being actively configured (non-default in minimal OpenDDS deployments); and the absence of a remote attack surface. The scope is contained to the local system with no scope change (S:U).

The CVSS 6.6 score with AV:L/AC:L/PR:L reflects a locally exploitable, low-complexity flaw requiring only a low-privileged account, which limits exposure in environments with strict host access controls but remains meaningful in shared or multi-tenant systems. EPSS of 0.15% (4th percentile) indicates very low observed exploitation probability, consistent with OpenDDS's niche industrial deployment footprint rather than broad consumer software. SSVC records exploitation status as 'poc' with automatable: no and technical impact: partial, meaning the proof-of-concept demonstrates reproducible crash behavior but no scalable, automated exploit chain is known. Even a mid-sized industrial or embedded system integrator in swidnica running OpenDDS-secured DDS participants should assess whether shared process contexts expose this DoS path to untrusted local accounts - in safety-critical or real-time control systems where participant continuity is essential, availability disruption carries outsized operational risk despite the moderate CVSS score. The absence from CISA KEV confirms no confirmed active exploitation. Notably, the provided CVSS assigns C:L and I:L impacts that are not directly supported by the description, which states only a denial of service outcome; this may overstate the overall score slightly.

A local attacker with a low-privileged account on a host running an OpenDDS 3.33.x DDS participant with DDS Security enabled constructs a malformed or specially crafted signed XML document and presents it to the verify() function. The improper signature validation triggers a fault condition - such as a crash or unhandled exception - terminating the participant process and disrupting real-time data distribution across the DDS domain. The proof-of-concept referenced via SSVC confirms this crash is reproducible, though no automated exploitation framework is known.