CVE-2023-50257 is a Critical severity (CVSS 9.6) access control flaw in eProsima Fast DDS, the middleware under many ROS 2 systems. Even with SROS2 on, the packets that disconnect nodes are not protected, so an attacker can cut subscribers off. Upgrade to 2.13.0, 2.12.2, 2.11.3, 2.10.3 or 2.6.7.
What's affected
Product: eProsima Fast DDS, formerly Fast RTPS. Affected: versions before 2.13.0, 2.12.2, 2.11.3, 2.10.3 and 2.6.7, per the GitHub advisory GHSA-v5r6-8mvh-cp98, which reads as one fixed release per supported line. Fixed: 2.13.0, 2.12.2, 2.11.3, 2.10.3 and 2.6.7. The advisory says the weakness has been present since the initial commit of the SecurityManager code in November 2016.
Distribution mapping from the advisory for ROS 2 users: on Iron, Fast DDS 2.10.2-2 is affected and 2.10.3 is the fix. On Humble, 2.6.6-1 is affected and 2.6.7 is the fix. For Galactic and Foxy, no fix is listed, because both reached end of life.
Severity: the record scores it 9.6 Critical with vector AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, and the advisory labels it Critical, so the sources agree. The attack vector is network adjacent, which means the attacker needs to be on the same network segment as the nodes. The advisory was published on 19 February 2024.
How to check if you're exposed
For ROS 2 on Debian based systems, check the installed Fast DDS package and its version.
dpkg -l | grep -i fastrtps
apt policy ros-humble-fastrtps
Replace humble with your ROS 2 distribution name. Compare the installed version with the fixed versions above. If you build Fast DDS from source or bundle it in your own application, check the version in your build files, and look at your SBOM if you keep one.
Also check whether DDS Security is in use. The issue is described as affecting systems that use SROS2, so the first question for each robot or device fleet is whether security is enabled and which Fast DDS version each device carries. Devices on Galactic or Foxy have no listed fix and need a distribution upgrade.
What to do now
- Upgrade Fast DDS to the fixed release for your line: 2.13.0, 2.12.2, 2.11.3, 2.10.3 or 2.6.7.
- If you run ROS 2 Galactic or Foxy, plan a move to a supported distribution, since the advisory lists no fix for them.
- Keep DDS traffic on an isolated network segment, so an attacker cannot reach the multicast discovery traffic.
- Rebuild images and firmware that bundle Fast DDS, and update fleets in stages, with a rollback plan.
- Add Fast DDS and its RMW wrapper to your component inventory so future advisories are matched automatically.
Why it matters
The weakness is CWE-284, improper access control. SROS2 adds authentication and encryption to ROS 2, but the advisory explains that the data and GUID values used to disconnect nodes were not encrypted. An attacker on the network can therefore send a disconnect message that is accepted, even though normal data traffic is protected.
The impact is availability and reliability. Subscribers lose their connection to the publisher, and if the attacker keeps sending the disconnect packet, new subscribers cannot connect either. In a robot or vehicle, a node that stops receiving data can mean a machine that stops working or falls back to a safe state. That is why the vector records high impact across the board, with a changed scope.
KEV status is false. The advisory itself contains technical detail and proof of concept material, which I have not reproduced here. For fleets, the sensible response is the version upgrade plus network segmentation. Safeguard's gold.safeguard.sh/scan scan and the Gold directory help you see which open source components, such as middleware libraries, sit in your repositories.
Quick check
Does SROS2 protect me?
Not against this issue. The advisory says that even with SROS2 applied, the disconnect data and GUID values were not encrypted.
What about ROS 2 Foxy and Galactic?
The advisory lists no fix for them because they reached end of life. Plan an upgrade to a supported distribution.
Sources
Last reviewed: 19 October 2026.
