dimos-robotics-skill

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:52 AM UTC
• Version: 1.0.0

Overview

The skill is a coherent DimOS robotics helper, but its included “safe” motion templates omit finite-number checks that can undermine robot movement limits.

Review before installing for robot-facing use. The skill is not deceptive and mostly promotes conservative robotics workflows, but its included safety examples should be fixed to reject NaN and other non-finite numeric inputs before any range checks or state updates. Use replay or simulation first, require local supervision for real hardware, and avoid exposing generated movement skills to MCP clients until numeric validation and downstream controller checks are confirmed.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: templates/safe_motion_skill.py:58
• Finding: Non-Finite Numeric Values Bypass Physical Motion Safety Limits<![CDATA[ ## Vulnerability Details **File Location**: `templates/safe_motion_skill.py`, lines 58–98 **Vulnerability Type**: Improper validation of non-finite floating-point values **Risk Level**: High ### Vulnerable Code ```python if max_forward_m <= 0 or max_left_m <= 0 or max_turn_degrees <= 0: return "Refused: all movement limits must be positive." if max_forward_m > 1.0 or max_left_m > 1.0 or max_turn_degrees > 90.0: return "Refused: requested limits are too large for a safe default wrapper." self.max_forward_m = max_forward_m self.max_left_m = max_left_m self.max_turn_degrees = max_turn_degrees return ( "Safe motion limits updated: " f"forward={self.max_forward_m} m, " f"left={self.max_left_m} m, " f"turn={self.max_turn_degrees} degrees." ) @skill def safe_relative_move( self, forward: float = 0.0, left: float = 0.0, degrees: float = 0.0, ) -> str: """Move the robot a small relative amount after validating safety limits. Args: forward: Forward/backward distance in meters. Positive is forward. left: Left/right distance in meters. Positive is left. degrees: Turn in degrees. Positive is counterclockwise. """ if abs(forward) > self.max_forward_m: return f"Refused: forward={forward} exceeds limit {self.max_forward_m}." if abs(left) > self.max_left_m: return f"Refused: left={left} exceeds limit {self.max_left_m}." if abs(degrees) > self.max_turn_degrees: return f"Refused: degrees={degrees} exceeds limit {self.max_turn_degrees}." if forward == 0.0 and left == 0.0 and degrees == 0.0: return "No movement requested." result = self._motion.relative_move(forward=forward, left=left, degrees=degrees) return f"Safe relative move requested. Underlying result: {result}" ``` ### Technical Analysis The validation relies exclusively on ordered comparisons. Under IEEE-754 floating-point semantics, comparisons such as `NaN <= 0`, `NaN > 1.0` ...[truncated 2096 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Reject all non-finite inputs before performing range comparisons or updating state: ```python from math import isfinite limits = (max_forward_m, max_left_m, max_turn_degrees) if not all(isfinite(value) for value in limits): return "Refused: all movement limits must be finite." if max_forward_m <= 0 or max_left_m <= 0 or max_turn_degrees <= 0: return "Refused: all movement limits must be positive." ``` Apply the same rule to every motion request: ```python values = (forward, left, degrees) if not all(isfinite(value) for value in values): return "Refused: all movement values must be finite." ``` Additional hardening should include: - Validate all fields before mutating any limit. - Keep immutable, trusted maximum ceilings separate from agent-configurable limits. - Consider removing `configure_safe_motion_limits` from agent-facing tools and loading limits from trusted deployment configuration. - Make the downstream motion provider independently validate finite values and enforce its own physical bounds. - Add unit tests for `NaN`, positive infinity, negative infinity, signed zero, exact boundaries, and values just above each boundary. - Verify whether the MCP JSON layer rejects non-standard numeric constants and configure strict JSON parsing where available. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: templates/spec_protocol_template.py:34
• Finding: Non-Finite Value Bypasses the Generic Bounded-Action Check<![CDATA[ ## Vulnerability Details **File Location**: `templates/spec_protocol_template.py`, lines 34–43 **Vulnerability Type**: Improper validation of non-finite floating-point values **Risk Level**: Medium ### Vulnerable Code ```python @skill def agent_action(self, value: float) -> str: """Ask the target module to perform a bounded action. Args: value: Action value. Keep this within the target module's safe range. """ if abs(value) > 1.0: return "Refused: value exceeds the safe range for this template." ok = self._target.perform_action(value) return "Action accepted by target module." if ok else "Target module rejected the action." ``` ### Technical Analysis The method is described as a bounded action, but it only evaluates `abs(value) > 1.0`. When `value` is `NaN`, `abs(value)` remains `NaN`, and the comparison evaluates to false. Execution therefore continues to `_target.perform_action(value)`. This is especially significant because the file is a reusable template. Developers may copy the pattern into skills connected to motors, actuators, navigation components, or other sensitive modules. ### Attack Path 1. A developer instantiates or copies this template into an MCP-enabled application. 2. A caller with access to `agent_action` supplies `NaN` through a transport accepting non-finite values or through direct Python/RPC invocation. 3. `abs(NaN) > 1.0` evaluates to false. 4. The supposedly bounded Skill invokes `_target.perform_action(NaN)`. 5. The target module processes an invalid value without protection from this wrapper. ### Impact Assessment This issue does not grant additional system privileges. It allows an existing Skill caller to bypass the advertised numeric range check and deliver invalid input to the target module. The resulting scope depends on the target implementation. Possible effects include target-module crashes, denial of service, corrupted calculations, undefined actuator behavior, or uns ...[truncated 158 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Require finite input before applying the numeric range: ```python from math import isfinite if not isfinite(value): return "Refused: value must be finite." if abs(value) > 1.0: return "Refused: value exceeds the safe range for this template." ``` Also: - Require the target module to enforce its own finite-value and range checks. - Document whether the valid range is inclusive and define units. - Add tests for `NaN`, both infinities, exact `-1.0` and `1.0` boundaries, and out-of-range finite values. - Configure the RPC or MCP serialization layer to reject non-standard numeric values where possible. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: resources/safety_and_testing.md:43
• Finding: Safety Documentation Recommends a Validation Pattern That Permits NaN<![CDATA[ ## Vulnerability Details **File Location**: `resources/safety_and_testing.md`, lines 43–47 **Vulnerability Type**: Insecure security guidance for physical motion validation **Risk Level**: Medium ### Vulnerable Code ```python if abs(forward) > self.max_forward_m: return f"Refused: forward={forward} exceeds limit {self.max_forward_m}." ``` ### Technical Analysis The documentation presents this code as the recommended input-validation pattern for robot movement. However, it does not first verify that `forward` and `self.max_forward_m` are finite. For `forward = NaN`, `abs(forward) > self.max_forward_m` evaluates to false. A skill implementing only this documented check would therefore permit execution to continue. A `NaN` limit similarly disables comparison-based enforcement for finite motion inputs. Because this guidance is intended to be copied into new physical-control skills, the problem can propagate beyond the included templates. ### Attack Path 1. A developer follows the documented input-validation pattern when implementing an agent-callable robot movement Skill. 2. The resulting Skill is exposed through MCP or another RPC path. 3. A caller provides `NaN` through a compatible parser or direct invocation path. 4. The recommended comparison does not reject the input. 5. The Skill forwards the non-finite value to its movement implementation. 6. The robot controller may fault, behave unpredictably, or process a command outside the intended safety model. ### Impact Assessment The documentation itself does not execute code and grants no direct privileges. Its security impact arises when developers adopt the incomplete pattern in deployed Skills. Affected generated implementations may expose denial-of-service conditions or unsafe physical-control behavior to callers already permitted to invoke those Skills. The eventual scope depends on where the copied pattern is used and whether downstream controllers perform independent validation. ]] ...[truncated 1 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Replace the documented pattern with explicit finite-value validation: ```python from math import isfinite if not isfinite(forward) or not isfinite(self.max_forward_m): return "Refused: movement values and limits must be finite." if abs(forward) > self.max_forward_m: return f"Refused: forward={forward} exceeds limit {self.max_forward_m}." ``` The guidance should also instruct developers to: - Validate every numeric motion parameter, including distance, speed, angle, and duration. - Validate configuration values before storing them. - Enforce limits again in the lowest-level motion provider. - Test `NaN`, positive infinity, negative infinity, boundaries, and malformed serialized inputs. - Use strict RPC and JSON deserialization settings that reject non-standard numeric constants where supported. ]]>

SkillSpector

Vulnerability Patterns

• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (1)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 95% confidence
• Finding: The skill describes workflows that use MCP and scaffolding/code-generation actions, but it does not declare any explicit tool scope such as permissions or allowed-tools. In an agentic robotics context, missing scope boundaries can let the hosting agent invoke broader file-write or MCP capabilities than intended, increasing the chance of unsafe code changes or unintended robot-facing actions.

Static analysis

No suspicious patterns detected.