Skip to main content
VulnerabilityPublished

CVE-2025-62603: eProsima Fast-DDS · Out-of-bounds Read

Affects eProsima Fast-DDSSource CVE Database V5

0

Not known to be exploited · CVSS 1.7 Low · fixed in 3.4.1 : update eProsima Fast-DDS when convenient.

Data as of 26 Oct 2026, 12:29 UTC

CVSS 4.0 base score
1.7Low
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.5% chance of exploitation in 30 days – higher than 46% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 3.4.1, 3.3.1, 2.6.11
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 3 Feb 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade eProsima Fast-DDS to 3.4.1, 3.3.1 or 2.6.11.

Affected software

ProductAffectedFixed in
eProsimaFast-DDSAffected
  • >=3.4.0 <3.4.1
Fixed in
  • 3.4.1
eProsimaFast-DDSAffected
  • >=3.0.0 <3.3.1
Fixed in
  • 3.3.1
eProsimaFast-DDSAffected
  • <2.6.11
Fixed in
  • 2.6.11
GitHubeprosima/Fast-DDSpkg:github/eprosima/Fast-DDSOther threatsAffected
  • =0
  • =3.0.0
  • =3.4.0
Fixed in–
GitHubFast-DDSpkg:github/Fast-DDSOther threatsAffected
  • >=3.4.0 <3.4.1
  • >=3.0.0 <3.3.1
  • <2.6.11
Fixed in
  • 3.4.1
  • 3.3.1
  • 2.6.11

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

The primary mitigation is to upgrade eProsima Fast-DDS to versions 3.4.1, 3.3.1, or 2.6.11 or later, where the vulnerability is patched. Organizations should audit their environments to identify Fast-DDS deployments and ensure timely patching. Network-level controls should be implemented to restrict DDS traffic to trusted sources only, employing firewall rules or network segmentation to isolate DDS communication channels. Deploying intrusion detection systems (IDS) or anomaly detection tailored to DDS traffic patterns can help identify malformed or suspicious messages. Additionally, applying rate limiting on DDS security messages may reduce the risk of resource exhaustion. Developers and integrators should review their use of ParticipantGenericMessage parsing to ensure minimal header checks are performed before full deserialization, reducing exposure to malformed inputs. Regular security assessments and penetration testing focusing on DDS implementations can help detect similar vulnerabilities proactively.

Description

Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). ParticipantGenericMessage is the DDS Security control-message container that carries not only the handshake but also on going security-control traffic after the handshake, such as crypto-token exchange, rekeying, re-authentication, and token delivery for newly appearing endpoints. On receive, the CDR parser is invoked first and deserializes the `message_data` (i .e., the `DataHolderSeq`) via the `readParticipantGenericMessage → readDataHolderSeq` path. The `DataHolderSeq` is parsed sequentially: a sequence count (`uint32`), and for each DataHolder the `class_id` string (e.g. `DDS:Auth:PKI-DH:1.0+Req`), string properties (a sequence of key/value pairs), and binary properties (a name plus an octet-vector). The parser operat es at a stateless level and does not know higher-layer state (for example, whether the handshake has already completed), s o it fully unfolds the structure before distinguishing legitimate from malformed traffic. Because RTPS permits duplicates, delays, and retransmissions, a receiver must perform at least minimal structural parsing to check identity and sequence n umbers before discarding or processing a message; the current implementation, however, does not "peek" only at a minimal header and instead parses the entire `DataHolderSeq`. As a result, prior to versions 3.4.1, 3.3.1, and 2.6.11, this parsi ng behavior can trigger an out-of-memory condition and remotely terminate the process. Versions 3.4.1, 3.3.1, and 2.6.11 p atch the issue.

References

Community reviews

Loading reviews…