huawei-cloud-cloudrobo-r2c

• Outcome: Review
• Latest audit: Sep 9, 2026 · 11:48 AM UTC
• Version: 1.0.0

Overview

The skill matches its robot-to-cloud purpose, but its verification script can start a live robot client with a real hardware configuration, so it needs review before use.

Review before installing or running. Use dummy configs and dry_run for testing, do not run the bundled verification script with production robot configs unless the robot is supervised and physically safe, protect the credential bundle and private-key password as secrets, prefer tls endpoints, and install only the minimal pinned packages you trust.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/test-cli-commands.sh:7
• Finding: Automated verification can unintentionally actuate real robot hardware<![CDATA[ ## Vulnerability Details **File Location**: `scripts/test-cli-commands.sh:7-8, 13-14, 35-45, 75-81, 96-104` **Vulnerability Type**: Unsafe test configuration and missing physical-actuation safeguards **Risk Level**: High ### Vulnerable Code ```bash # Environment variables: # BUNDLE_PATH - Path to credential bundle zip (for client tests) # ROBOT_CONFIG - Path to robot config YAML (default: config/robot_dummy_config.yaml) # DURATION - Test duration in seconds (default: 10) BUNDLE_PATH=${BUNDLE_PATH:-} ROBOT_CONFIG=${ROBOT_CONFIG:-config/robot_dummy_config.yaml} DURATION=${DURATION:-10} ``` Test 1 is described as a dummy-adapter test, but it accepts the caller-controlled configuration without validating the adapter type or forcing dry-run mode: ```bash # Test 1: Client startup with dummy adapter (requires bundle) echo "Test 1: Start R2C client (dummy adapter, ${DURATION}s)" if [ -n "$BUNDLE_PATH" ] && [ -f "$BUNDLE_PATH" ]; then echo " Starting client for ${DURATION}s..." timeout "$DURATION" cloudrobo r2c client \ --bundle "$BUNDLE_PATH" \ --robot-config "$ROBOT_CONFIG" \ --duration "$DURATION" \ --log-level INFO 2>&1 || true echo " Client test completed." else echo " Skipping: BUNDLE_PATH not set or file not found" echo " Set BUNDLE_PATH env var to test client startup" fi ``` The recording and logging tests reuse the same unrestricted configuration: ```bash # Test 3: Observation recording test if [ -n "$BUNDLE_PATH" ] && [ -f "$BUNDLE_PATH" ]; then echo " Recording observations for ${DURATION}s..." timeout "$DURATION" cloudrobo r2c client \ --bundle "$BUNDLE_PATH" \ --robot-config "$ROBOT_CONFIG" \ --duration "$DURATION" \ --record /tmp/r2c_test_observations.pkl \ --log-level INFO 2>&1 || true ``` ```bash # Test 5: Log file test if [ -n "$BUNDLE_PATH" ] && [ -f "$BUNDLE_PATH" ]; then LOG_FILE="/tmp/r2c_test.log" timeout 5 cloudrobo r2c cl ...[truncated 2546 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Generate a dedicated test configuration instead of accepting an unrestricted production robot configuration. 2. Parse and validate the YAML before every client invocation: - Require `hardware.type: dummy` for automated verification. - Require `runtime.dry_run: true`. - Abort if either condition is not met. 3. Force dry-run mode for Tests 1, 3, and 5 rather than relying on the input configuration. 4. Add a separate explicit option such as `--allow-real-hardware`, disabled by default, for controlled integration testing. 5. Before accepting that option, display the adapter type, endpoint, robot identity, and actuation status and require affirmative confirmation. 6. Do not suppress unexpected failures with unconditional `|| true`. Capture the exit code and fail the test when startup, validation, or shutdown does not behave as expected. 7. Require physical safety controls for real-hardware tests, including an emergency stop, cleared operating area, joint and velocity limits, and operator supervision. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/test-cli-commands.sh:57
• Finding: Predictable shared temporary files permit symlink-based file overwrite<![CDATA[ ## Vulnerability Details **File Location**: `scripts/test-cli-commands.sh:57-64, 80-84, 97-109` **Vulnerability Type**: Insecure temporary-file creation **Risk Level**: Medium ### Vulnerable Code The dry-run configuration uses a fixed path in the shared `/tmp` directory: ```bash # Create a temporary dry_run config DRY_RUN_CONFIG="/tmp/r2c_dryrun_config.yaml" if [ -f "$ROBOT_CONFIG" ]; then sed 's/dry_run: false/dry_run: true/g' "$ROBOT_CONFIG" > "$DRY_RUN_CONFIG" timeout "$DURATION" cloudrobo r2c client \ --bundle "$BUNDLE_PATH" \ --robot-config "$DRY_RUN_CONFIG" \ --duration "$DURATION" \ --log-level DEBUG 2>&1 || true rm -f "$DRY_RUN_CONFIG" fi ``` The observation recording also uses a fixed shared path: ```bash timeout "$DURATION" cloudrobo r2c client \ --bundle "$BUNDLE_PATH" \ --robot-config "$ROBOT_CONFIG" \ --duration "$DURATION" \ --record /tmp/r2c_test_observations.pkl \ --log-level INFO 2>&1 || true if [ -f /tmp/r2c_test_observations.pkl ]; then echo " Recording file created: $(ls -la /tmp/r2c_test_observations.pkl)" rm -f /tmp/r2c_test_observations.pkl fi ``` The log test follows the same pattern: ```bash LOG_FILE="/tmp/r2c_test.log" timeout 5 cloudrobo r2c client \ --bundle "$BUNDLE_PATH" \ --robot-config "$ROBOT_CONFIG" \ --duration 5 \ --log-file "$LOG_FILE" \ --log-level DEBUG 2>&1 || true if [ -f "$LOG_FILE" ]; then echo " Log file created: $(ls -la "$LOG_FILE")" rm -f "$LOG_FILE" else echo " Warning: log file not created" fi ``` ### Technical Analysis The script creates or writes files under predictable names in a globally shared temporary directory. It does not use `mktemp`, exclusive file creation, ownership validation, symbolic-link checks, or a user-private temporary directory. For the dry-run configuration, shell redirection opens `/tmp/r2c_dryrun_config.yaml` before `sed` runs. If another local user has pre-created that path as a symbolic li ...[truncated 1950 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Create a private temporary directory atomically: ```bash umask 077 TMP_DIR="$(mktemp -d "${TMPDIR:-/tmp}/cloudrobo-r2c-test.XXXXXX")" trap 'rm -rf -- "$TMP_DIR"' EXIT HUP INT TERM ``` 2. Store all generated artifacts under that private directory: ```bash DRY_RUN_CONFIG="$TMP_DIR/dryrun-config.yaml" RECORD_FILE="$TMP_DIR/observations.pkl" LOG_FILE="$TMP_DIR/r2c.log" ``` 3. Avoid fixed global filenames. 4. Ensure the temporary directory is owned by the current user and has mode `0700`. 5. Where supported, create output files with exclusive-create semantics and reject existing paths. 6. Verify that output paths are regular files owned by the current user before reading, reporting, or deleting them. 7. Use the cleanup trap instead of repeated ad hoc `rm -f` commands so cleanup also occurs on interruption or failure. 8. Never run this verification script with unnecessary elevated privileges. ]]>

T08 · Insecure Dependencies

Warning

• Location: references/cli-installation-guide.md:6
• Finding: Installation guidance executes unpinned third-party packages<![CDATA[ ## Vulnerability Details **File Location**: `references/cli-installation-guide.md:6-44, 191` **Vulnerability Type**: Unpinned executable dependencies and excessive optional dependency surface **Risk Level**: Medium ### Vulnerable Code The installation guide recommends packages without versions, hashes, constraints, or an explicitly trusted package index: ```bash pip install hw-cloudrobo-client ``` ```bash pip install hw-cloudrobo-r2c ``` ```bash # R2C client with Zenoh transport, Protobuf, and media processing pip install hw-cloudrobo-r2c[client] # Cloud adapter with Zenoh transport and Protobuf pip install hw-cloudrobo-r2c[cloud-adapter] # UR5e robot support (ur-rtde, pyserial, pyrealsense2) pip install hw-cloudrobo-r2c[ur5e] # Flexiv robot support (flexivrdk, Linux x86_64 only) pip install hw-cloudrobo-r2c[flexiv] # Jaka robot support (scipy) pip install hw-cloudrobo-r2c[jaka] # A1Z robot support (python-can, pin) pip install hw-cloudrobo-r2c[a1z] # All extras pip install hw-cloudrobo-r2c[all] ``` The troubleshooting guidance introduces another unpinned package: ```text | `ImportError: openpi_client` | Install with `pip install hw-cloudrobo-r2c[cloud-adapter]` and `pip install openpi-client` | ``` ### Technical Analysis Python packages and their transitive dependencies execute code in the user's environment during installation, import, plugin discovery, or application startup. These commands accept whichever compatible package versions the configured Python package index currently serves. No reviewed version constraints, lock file, constraints file, cryptographic hashes, or authenticated internal index are specified. The `[all]` extra expands the dependency graph to hardware SDKs, transport libraries, media components, and platform-specific packages that may not be required for the user's task. This creates exposure to: - Compromise of a named package or one of its transitive dependencies - A malicious future release - Dependency c ...[truncated 1922 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin every direct dependency to reviewed versions. 2. Publish and use a constraints or lock file covering transitive dependencies. 3. Require hashes for reproducible installation, for example with `pip install --require-hashes`. 4. Specify the authenticated, trusted package repository from which CloudRobo packages must be obtained. 5. Document package publisher identity and release-verification procedures. 6. Prefer minimal extras such as `[client]` over `[all]`; install hardware-specific extras only when required. 7. Scan pinned packages and transitive dependencies for known vulnerabilities before release. 8. Build wheels in a controlled environment and install from an approved artifact repository where possible. 9. Use an isolated virtual environment and avoid installation as root. 10. Review adapter entry points before enabling third-party adapter packages, because imported entry points execute with the full authority of the robot-client process. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (5)

Missing User Warnings

Low

• Confidence: 91% confidence
• Finding: The acceptance criteria explicitly instruct starting the robot edge client with a credential bundle or client config, which can create live network connections and interact with robot-side systems, but the file does not pair these steps with a user-facing warning or confirmation requirement. In this skill context, that omission is meaningful because the client is not a passive reader: even short test runs may authenticate to cloud services, publish telemetry, and potentially participate in control flows unless clearly constrained.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The guide instructs users to export, pass around, and use an mTLS credential bundle containing a private key and certificate material, but it does not clearly warn that the bundle is highly sensitive or provide handling precautions. In this R2C context, disclosure of the bundle or password could let an attacker impersonate the robot on the data plane or misuse device identity and connectivity settings.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The documentation explicitly presents `tcp` as a valid endpoint format and even uses a plaintext TCP example, but it does not clearly warn that using `tcp/` sends robot telemetry and tenant/device identifiers without transport encryption. In this robot-to-cloud context, that can expose operational data and metadata to network observers and enables easier interception or manipulation on untrusted networks.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The dry-run flow explicitly says that real hardware observations are still collected and published to Zenoh while only action execution is suppressed. In a robotics/robot-to-cloud context, those observations can include sensitive operational, environmental, or location-derived data, so omitting an explicit warning can mislead users into believing dry-run is fully non-invasive and cause unintended data exposure.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The documentation describes enabling `keyboard_control` and custom key mappings that can invoke commands like `go_home` or `state`, but it does not clearly warn that these keystrokes may trigger real robot actions on connected hardware. In an R2C client skill that bridges cloud actions to physical devices, this omission can lead operators to enable the feature in production and unintentionally cause motion or state-changing behavior.

Static analysis

No suspicious patterns detected.