T09 · Insecure Skill Coding Practices
- Location
core/coordinator.py:153- Finding
Concurrent Commands Can Be Sent to the Same Physical Robot
- Content
View full analysis
ExecutionResult: """Execute a parallel task.""" subtask_results = self._execute_batch(task.subtasks) ``` ### Technical Analysis `Coordinator._execute_batch()` submits every task in a batch to a shared `ThreadPoolExecutor`. It does not group tasks by robot or acquire a lock associated with `task.robot`. Consequently, two tasks assigned to the same robot can invoke the same adapter's `execute_action()` method concurrently. The adapters only update a shared `busy` flag; they do not use that flag as an atomic exclusion mechanism. The shared `requests.Session` objects are also used concurrently without adapter-level synchronization. This contradicts the documented claim that tasks for the same robot are automatically serialized. ### Attack Path 1. An operator, Agent, or untrusted plan source creates two atomic tasks that reference the same registered robot. 2. The tasks are placed in the same dependency batch or inside a parallel task group. 3. `_execute_batch()` submits both tasks to separate worker threads. 4. Both workers reach the robot adapter's `execute_action()` method concurrently. 5. Conflicting commands, such as movement and release commands, are transmitted to the same physical robot without coordination. No operating-system privilege escalation is required. Exploitation requires the ability to submit or influence task plans for a registered robot. ### Impact Assessment The flaw can produce conflicting physica ...[truncated 457 chars]- Remediation
View remediation
