T09 · Insecure Skill Coding Practices
- Location
references/my_private_devices.md:1- Finding
Private Xiaomi Device Credentials Committed in Plaintext
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill needs Review because it ships and encourages plaintext Xiaomi device credentials and includes broad cloud token extraction with unsafe secret handling, though I found no clear exfiltration or backdoor.
Do not install this version unless the private credentials have been removed and rotated, token storage has been moved out of Markdown/source files, secret-bearing logs and plaintext exports have been fixed, and cloud token extraction is clearly scoped and consented. Treat any included Xiaomi tokens, BLE keys, router/camera details, and generated debug logs as sensitive credentials.
references/my_private_devices.md:1Private Xiaomi Device Credentials Committed in Plaintext
SKILL.md:25Users Are Directed to Store Device Tokens in Agent-Readable Markdown
scripts/token_extractor.py:324Debug Logging Exposes Xiaomi Authentication Secrets
scripts/token_extractor.py:778QR and CAPTCHA Images Are Served on All Network Interfaces
scripts/token_extractor.py:47Xiaomi Account Password Can Be Passed Through Process-Visible Arguments
scripts/token_extractor.py:885Extracted Device Credentials Are Written Without Enforced Restrictive Permissions
SKILL.md:4Installation Executes Unpinned Third-Party Packages
The skill claims to perform local LAN control via miiocli, but the documented behavior and referenced bundled script include Xiaomi cloud login, account/session handling, device inventory retrieval, and token extraction. This mismatch is dangerous because users may authorize a seemingly local-control skill without realizing it collects sensitive cloud-derived credentials that enable control of physical devices.
The file contains plaintext Xiaomi device tokens, private IP addresses, and device inventory details for multiple networks. These tokens can enable unauthorized control of local smart devices and expose sensitive infrastructure information; in the context of a Xiaomi Home control skill, the credentials are directly actionable and substantially increase the risk of device compromise, surveillance abuse, or lateral targeting on the LAN.
This script performs Xiaomi cloud authentication, enumerates homes/devices across regions, and extracts device tokens and BLE beacon keys. That behavior materially exceeds the skill's stated LAN-only local-control purpose, creating an overprivileged credential-harvesting capability that could expose the user's cloud account and enable broader device compromise.
Debug logging includes the full login request fields, which contain the username and password-derived MD5 hash. Even if not the plaintext password, this is sensitive authentication material that can be reused for offline attacks, credential correlation, or account compromise if logs are exposed.
The script logs recovered session secrets such as ssecurity/psecurity from the extension-pragma header. These values are session-critical and can allow an attacker with log access to hijack authenticated API activity or derive further protected requests.
The script prints device tokens and BLE keys to the console and can persist them to disk in the output file. These secrets enable control or impersonation of Xiaomi devices, so exposing them without strong safeguards significantly increases the risk of device takeover and lateral misuse.
The skill declares executable installation steps and documents networked/cloud interactions plus local credential storage, but it does not declare any explicit tool scope or permissions boundary. That makes the skill harder to sandbox and review, and can allow broader-than-expected file-write or network access during installation and operation.
The manifest emphasizes local LAN control, but the setup instructions direct users to fetch device IPs and tokens from Xiaomi Cloud. This is sensitive credential acquisition, and presenting it as routine setup without clear disclosure can mislead users into exposing account-linked device secrets.
Built-in token extraction from Xiaomi Cloud exceeds the narrowly stated purpose of local device control and grants access to secrets that can be reused outside this skill. In the context of smart-home control, leaked or mishandled tokens can enable unauthorized control, device inventory disclosure, and persistence of access beyond a single session.
The skill describes extracting Xiaomi device tokens and storing device details locally but does not warn that these are sensitive credentials. Users may place tokens in markdown/reference files without understanding that anyone with file access could reuse them to control devices on the local network.
The natural-language intent section maps casual user phrases directly to power-state and property-changing commands for real-world devices, but it lacks any warning or confirmation guidance. In a home-automation context, silent execution can cause unsafe or unintended physical actions, especially for appliances like heaters or cookers.
The template explicitly tells users to record device IPs and authentication tokens in a markdown file, but provides no warning that tokens are sensitive secrets or guidance on protecting them. In the context of a Xiaomi LAN-control skill, those tokens can enable unauthorized control of smart-home devices if the file is exposed through source control, backups, logs, or shared workspaces.
The script starts an HTTP server bound to all interfaces on port 31415 to serve QR/captcha images. Even though intended for convenience, exposing a local unauthenticated server is unnecessary to core device control and can leak login artifacts to other hosts on the network or broaden the attack surface.
The document mixes English headings with device names presented in Chinese, but provides no indication that the locale is optional, user-selected, or required for a region-specific purpose. Under the language/locale policy, forcing a specific language without opt-in can be a natural-language policy violation.
The code sets locale values such as en_GB and later en_US in multiple request parameters and cookies, forcing a specific locale behavior. There is no user opt-in or documentation explaining why English locales are required, which fits the language/locale policy concern.
No suspicious patterns detected.