CVE-2024-42002 in Robot Operating System
Summary
by MITRE • 09/29/2026
A code injection vulnerability has been discovered in the Robot Operating System 2 (ROS 2) 'ros2topic' command-line tool, affecting all ROS 2 distributions from Crystal Clemmys up to and including Lyrical Luth and Rolling Ridley. The vulnerability lies in the 'hz' verb, which reports the publishing rate of a topic and accepts a user-provided Python expression via the --filter option. This input is passed directly to the eval() function without sanitization, allowing a local user to craft and execute arbitrary code.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/29/2026
The Robot Operating System 2 (ROS 2) ecosystem, widely utilized in robotics research and development for its modular architecture and communication capabilities, contains a critical security flaw within the ros2topic command-line utility. This vulnerability affects all distributions from Crystal Clemmys through Lyrical Luth and Rolling Ridley, indicating a long-standing issue that has persisted across multiple release cycles without adequate remediation. The core of the problem resides in the hz verb functionality, which is designed to monitor and report the publishing rate of specific ROS topics. While this feature provides valuable diagnostic information for developers debugging system performance or data flow, it introduces a significant attack surface by accepting user-defined Python expressions through the --filter option. This design choice prioritizes flexibility over security, allowing users to apply dynamic filters to topic data streams based on custom logic defined at runtime.
The technical root cause of this vulnerability is the direct invocation of the Python eval() function on unsanitized input provided via the --filter argument. In software development, particularly when dealing with scripting languages like Python, passing user-controlled strings directly into an execution context such as eval() is a well-documented anti-pattern that leads to code injection vulnerabilities. Because ROS 2 tools typically run with the privileges of the invoking user in local environments, this lack of input validation allows any local user who has access to the terminal or can interact with the system's process space to inject arbitrary Python commands. The vulnerability does not require network exposure; it is strictly a local privilege escalation vector that exploits trust assumptions within development workflows where users are accustomed to running tools with elevated permissions for hardware interaction and debugging purposes.
From an operational perspective, this code injection flaw enables an attacker to execute arbitrary system commands under the context of the user running the ROS 2 tool. This can lead to complete compromise of the local environment, including theft of sensitive data such as cryptographic keys or configuration files, installation of malware, or use of the compromised node as a pivot point for further attacks within the networked robotics infrastructure. In industrial or autonomous systems where ROS is deployed, an attacker with physical access could exploit this flaw to disrupt operations by injecting malicious logic that alters sensor readings, manipulates control loops, or causes denial-of-service conditions through resource exhaustion via infinite loops in injected code. The impact extends beyond simple data exfiltration to potential safety hazards if the compromised system controls critical machinery or autonomous vehicles.
This vulnerability aligns with Common Weakness Enumeration (CWE) ID 94, commonly known as Improper Control of Generation of Code ('Code Injection'), and specifically CWE-78 for OS Command Injection when the injected Python code results in shell command execution. In terms of tactical classification within the MITRE ATT&CK framework, this flaw facilitates Initial Access via Local Exploitation of a Trusted Application or Privilege Escalation if the ROS tool is run with higher privileges than intended. It also relates to CWE-95 for Improper Neutralization of Special Elements used in an OS Command ('Eval Injection'). The persistence of this issue across multiple distributions highlights a gap in security review processes during feature development, where functional requirements were prioritized over secure coding practices regarding dynamic code evaluation.
Mitigation strategies must focus on eliminating the use of eval() with untrusted input entirely. Developers should replace the current implementation with safer alternatives such as ast.literal_eval for parsing literal structures or implementing a restricted expression parser that only allows specific mathematical or logical operations without full Python execution capabilities. For users unable to immediately upgrade, restricting file permissions so that non-privileged users cannot execute ros2topic commands can provide temporary relief, though this is not a robust solution given the tool's utility in development workflows. Organizations deploying ROS 2 should also implement strict input validation policies and consider using containerization or sandboxing techniques to isolate ROS processes from critical system resources. Regular security audits of third-party robotics software are essential to identify similar patterns where convenience features introduce severe execution risks, ensuring that future updates prioritize secure-by-design principles over flexible but dangerous functionality.