Summary
A code injection vulnerability in the ROS 2 ros2topic hz command allows a local user to provide a Python expression through the --filter option. Because the expression is passed directly to Python's eval() without adequate sanitization, crafted input may execute arbitrary code with the permissions of the invoking process.
Affected context
The issue occurs in ROS 2 distributions that include the affected ros2topic command-line implementation and expose the hz verb's --filter option. Risk is present when a local user can invoke this command and supply or influence the filter expression, particularly in environments where the command runs with elevated permissions or access to sensitive robotics resources.
Exploit preconditions
- Attack surface: The local ROS 2 command-line interface
- Required access: Ability to run
ros2topic hzand provide the--filteroption - Trigger point: Processing of the user-supplied filter expression
- Why exploitation is possible: The expression is evaluated as Python code through
eval()without sufficient restriction or sanitization
Why this happens
The underlying flaw is the use of a general-purpose dynamic evaluation function on user-controlled input. Python's eval() interprets supplied text as executable code rather than treating it as inert data or a constrained expression. This behavior maps primarily to CWE-94: Improper Control of Generation of Code, with CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code also applicable.
Potential impact
- A local attacker may execute arbitrary Python or operating-system commands
- The attacker could access or modify files available to the ROS 2 process
- Sensitive robotics data, credentials, or configuration may be exposed
- Running processes, topics, or connected robot functions could be disrupted
- Compromise could spread to other systems reachable from the affected host
General mitigation guidance
Mitigation generally focuses on removing dynamic evaluation of user-provided expressions and reducing the trust placed in command-line input.
Common defensive patterns include:
- Replacing
eval()with a narrowly defined, non-executable filter language - Parsing expressions with an allowlisted grammar and explicit permitted operations
- Validating input types and structure before processing
- Avoiding execution of command-line values as code or shell commands
- Running ROS 2 tooling with least-privilege operating-system and ROS permissions
- Separating monitoring functionality from sensitive robot-control capabilities
How teams detect issues like this
Organizations can identify similar risks through:
- Static analysis rules that flag
eval(),exec(), and comparable dynamic evaluation APIs - Code review checks for user-controlled values reaching interpreters or expression engines
- Searches for command-line arguments passed into Python evaluation, shell execution, or template engines
- Policy enforcement that prohibits unrestricted code evaluation in production tooling
- Runtime monitoring for unexpected child processes, file access, or network activity from ROS 2 utilities
Automated security scanning and code review tools can help detect these patterns when configured to track data flow from CLI arguments.
