Back to skill

Security audit

小米/米家智能家居控制

Security checks for vulnerabilities and agentic risk

Overview

This Xiaomi smart-home skill is coherent for device control, but it asks for account passwords and verification codes in chat and can trigger broad physical and camera actions without enough safeguards.

Review before installing. Only use this with an MCP server you fully trust, and avoid entering Xiaomi passwords or verification codes into ordinary chat unless you understand where they are stored and logged. Require explicit confirmation for scenes, bulk device changes, heaters/climate devices, and any camera snapshot or RTSP camera setup.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:12
Finding
Xiaomi Account Password and Verification Code Exposed to an Unspecified MCP Server## Vulnerability Details **File Location**: `SKILL.md`, lines 12–21 **Vulnerability Type**: Sensitive credential exposure **Risk Level**: High ### Evidence The relevant instructions state: ```text Whenever a device-control request is received, first call xiaomi_auth_status to check authentication status. If the status is not_configured or not_authenticated: 1. Tell the user that a Xiaomi account and password are required. 2. After the user provides them, call xiaomi_setup(username, password, country) to initiate login. 3. If verification_required is returned, tell the user to check their phone or email for a verification code. 4. After the user provides the code, call xiaomi_verify(code). 5. Continue the original device-control request after authentication. ``` ### Technical Analysis The Skill instructs the user to disclose a Xiaomi account password and a second-factor verification code directly in the agent conversation. It then forwards both authentication factors to an MCP implementation that is not included in the audited project. The project provides no auditable guarantees concerning the MCP server's identity, transport security, credential storage, logging, retention, deletion, or access controls. It also does not warn the agent to prevent passwords and verification codes from appearing in conversation history, telemetry, or tool-call logs. This violates least-exposure principles for authentication secrets. A browser-based authorization flow or a narrowly scoped token would prevent the agent and MCP tool interface from handling the user's reusable account password. ### Attack Path 1. The user requests control of a Xiaomi smart-home device. 2. The Skill calls `xiaomi_auth_status`. 3. An unauthenticated status causes the Skill to request the user's Xiaomi username and password. 4. The agent forwards those credentials through `xiaomi_setup`. 5. The Skill subsequently requests a phone or e ...[truncated 941 chars]
Remediation
## Remediation Suggestions - Replace direct password collection with Xiaomi's official browser-based OAuth, device authorization, or delegated token flow where available. - Do not place passwords or one-time verification codes in model-visible conversation content. - Use a trusted credential broker or operating-system secret store if direct credential handling is unavoidable. - Require a pinned and authenticated MCP server identity rather than relying on an unspecified implementation. - Document the MCP endpoint, transport encryption, credential-storage policy, retention period, logging behavior, and deletion procedure. - Use narrowly scoped and revocable tokens instead of reusable account passwords. - Redact authentication secrets from tool-call logs, application telemetry, errors, and conversation history. - Display a clear trust and privacy warning before transferring any authentication material to an external component.

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:132
Finding
Unrestricted Local Image Access Through MCP-Provided Paths and Mock Camera Sources## Vulnerability Details **File Location**: `SKILL.md`, lines 132–140 **Vulnerability Type**: Unbounded local-file access **Risk Level**: Medium ### Evidence The relevant instructions state: ```text When the user wants to look at a location, use camera snapshots: 1. Call xiaomi_camera_list to identify available cameras. 2. Call xiaomi_camera_snapshot(name) to capture an image. 3. Use the Read tool to read the returned image path and analyze it. 4. Describe the image and suggest related device actions. When adding a camera, use xiaomi_camera_add(name, rtsp_url). For testing, mock://file-name or mock://directory-name may load local images. ``` ### Technical Analysis The Skill instructs the agent to pass a path returned by the MCP server to the privileged `Read` tool. It also explicitly supports local files and directories through the `mock://` scheme. No restriction limits reads to a dedicated camera-snapshot or test-fixture directory. The instructions do not require path canonicalization, traversal rejection, symbolic-link validation, image-format verification, file-size limits, or explicit user approval before opening a local path. Consequently, a crafted camera source or malicious MCP response could point the agent at an unrelated local image. Directory support may further broaden the accessible set of files. Although the workflow expects images, relying only on a filename or URI scheme is not an adequate access-control boundary. ### Attack Path 1. An attacker with camera-configuration access registers a crafted `mock://` source, or a compromised MCP server returns an attacker-selected local path. 2. The user issues a camera-related request such as asking the agent to inspect that location. 3. The Skill calls `xiaomi_camera_snapshot`. 4. The MCP server returns the crafted local path. 5. Following the Skill instructions, the agent invokes the `Read` tool on that path. 6. The agent analyzes and describe ...[truncated 619 chars]
Remediation
## Remediation Suggestions - Remove `mock://` local-file support from production instructions. - If mock sources are required for testing, confine them to a dedicated, read-only fixture directory inside a sandbox. - Canonicalize every returned path before access and verify that it remains under the approved snapshot directory. - Reject absolute paths, parent-directory traversal, unexpected URI schemes, and symbolic links that resolve outside the approved directory. - Permit only validated image formats and enforce conservative file-size and image-dimension limits. - Do not allow whole-directory ingestion unless it is strictly necessary and separately authorized. - Treat MCP-returned paths as untrusted input. - Show the canonical path and obtain explicit user approval before reading a local mock file. - Prefer transferring snapshot bytes through a constrained camera API instead of granting the agent filesystem-path access.

other

Warning
Location
SKILL.md:117
Finding
Ambiguous Scene Phrases Can Trigger Unconfirmed Multi-Device Physical Actions## Vulnerability Details **File Location**: `SKILL.md`, lines 117–124; broad triggering behavior is also defined at line 3 **Vulnerability Type**: Unsafe physical-device actuation **Risk Level**: Medium ### Evidence The relevant scene instructions state: ```text Users may describe a scene rather than a single-device operation: - "I am going to sleep" -> turn off lights, set the purifier to sleep mode, and lower the electric heater. - "I am leaving" -> turn off all devices. - "The living room is too dark" -> turn on lights and increase brightness. - "Look at the entrance" -> capture a snapshot, analyze it, and suggest linked actions. For scene instructions, decompose the request into multiple device operations, execute them in sequence, and report the result. ``` The Skill metadata also states that it should trigger for any smart-home control request, even if the user does not explicitly mention Xiaomi or Mi Home. ### Technical Analysis The Skill maps conversational and potentially ambiguous phrases directly to multiple physical-device operations. It instructs the agent to execute the derived operations sequentially, but it does not require a confirmation step, preview the affected devices, or distinguish low-risk convenience devices from climate, heating, security, or camera equipment. The instruction to turn off all devices is especially broad. Device discovery may include equipment whose shutdown was not intended by the user. The broad trigger rule also creates a routing risk when the user owns multiple smart-home platforms or is describing a situation rather than issuing a command. This is not evidence of malicious behavior, but it is an unsafe authorization design for physical actuation. Natural-language inference should not substitute for explicit authorization when a phrase expands into bulk or safety-relevant actions. ### Attack Path 1. The user makes an ambiguous statement such as “I am leavin ...[truncated 1087 chars]
Remediation
## Remediation Suggestions - Require explicit confirmation before executing inferred scenes, bulk operations, or changes affecting multiple devices. - Present a preview listing every target device, current state, proposed state, and operation before execution. - Require separate confirmation for heaters, climate-control equipment, cameras, locks, alarms, and other safety- or privacy-sensitive devices. - Interpret ambiguous statements as suggestions or clarification prompts rather than immediate authorization. - Scope phrases such as “all devices” to a user-approved allowlist of noncritical equipment. - Ask which smart-home platform or household the user intends when routing is ambiguous. - Support user-defined scenes with explicit device membership instead of inferring scene contents on every invocation. - Provide cancellation and rollback behavior for partially completed multi-device scenes where the device APIs support it. - Record an auditable summary of confirmed actions without storing sensitive camera content or authentication data.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (6)

Vague Triggers

High
Confidence
97% confidence
Finding
The activation rule is overly broad: it triggers on essentially any home-device-related request, even when the user does not explicitly reference Xiaomi or Mi Home. Overbroad triggering raises the risk of unintended invocation, accidental execution of real-world actions, and capture of sensitive household context when another skill or a clarification step would be more appropriate.

Missing User Warnings

High
Confidence
97% confidence
Finding
The skill directs users to provide their Xiaomi account username and password directly in conversation, without any credential-safety warning or secure handoff. Collecting primary credentials through chat is dangerous because it trains unsafe behavior, risks credential exposure in logs/transcripts, and exceeds least-privilege expectations for a smart-home skill.

Description-Behavior Mismatch

Medium
Confidence
91% confidence
Finding
The skill’s declared purpose is smart-home device control, but it also exposes camera surveillance and image-analysis workflows. This capability expansion increases access to sensitive visual data and creates a privacy-impacting behavior users may not reasonably expect from a device-control skill.

Context-Inappropriate Capability

Medium
Confidence
88% confidence
Finding
Allowing the skill to add or remove cameras via RTSP URLs goes beyond routine appliance control and introduces a pathway to ingest or reconfigure surveillance sources. This can expose sensitive feeds, enable unauthorized monitoring, or connect the skill to arbitrary network streams if not tightly constrained.

Context-Inappropriate Capability

Medium
Confidence
93% confidence
Finding
The instruction to use a generic Read tool on snapshot file paths expands the skill from device control into arbitrary file access and image analysis. Even if intended for snapshots, this pattern can blur trust boundaries and create opportunities to read unintended local files or process sensitive image data outside the camera tool’s intended sandbox.

Vague Triggers

Medium
Confidence
92% confidence
Finding
Camera trigger phrases like '看看' and similar casual expressions are vague and common in ordinary conversation. This can cause the skill to activate surveillance behavior unexpectedly, leading to privacy-invasive snapshot capture or image analysis without sufficiently explicit user intent.

Static analysis

No suspicious patterns detected.