T09 · Insecure Skill Coding Practices
- Location
SKILL.md:38- Finding
Plaintext and Unnecessary Collection of High-Value Smart-Home Credentials
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This smart-home skill is purpose-related but needs Review because it asks users to store high-value smart-home and account credentials in plaintext while making unsupported security and capability claims.
Install only after treating this as a prototype: do not put Xiaomi, Apple, HomeKit, or device secrets in TOOLS.md; avoid paid plans or relying on advertised automation until the publisher documents implemented features, secure secret storage, privacy practices, and exact supported devices. Review the code and dependency versions before connecting real devices.
SKILL.md:38Plaintext and Unnecessary Collection of High-Value Smart-Home Credentials
package.json:25Unpinned and Redundantly Installed Third-Party Dependencies
README.md:1False Security and Capability Claims Encourage Unsafe Credential Disclosure and Payment
The marketing copy explicitly reassures users that credentials are encrypted locally while promoting integration across multiple platforms, but it does not explain what credentials are collected, how they are handled, or what telemetry may accompany use of the product. In a smart-home context, platform credentials can grant broad access to devices, routines, and occupancy-related data, so omission of clear privacy and data-handling disclosures can mislead users into sharing sensitive access without informed consent.
The tracking plan documents use of ClawHub backend data, Google Analytics, coupon tracking, and user feedback collection, but nowhere indicates that users will be informed or given consent choices regarding telemetry and monitoring. Because this product manages smart-home usage, analytics can reveal behavior patterns, device ownership, and occupancy habits, making undisclosed tracking a meaningful privacy risk.
The document advertises AI analysis of household electricity habits and automatic shutdown/control of devices without warning users that this requires behavior profiling and may trigger system-impacting automation. In a smart-home environment, such automation can affect HVAC, heating, and other essential devices, creating privacy concerns and potential safety or availability issues if actions are wrong or unexpected.
The report promotes security monitoring features such as door/window sensors, camera anomaly detection, and gas/water leak alerts without any visible warning about what data is collected, how long it is retained, who can access it, or the consequences of false positives and remote notifications. In a smart-home context, these capabilities can expose highly sensitive occupancy and household-behavior data, so omitting privacy and operational warnings is a real user-safety and privacy issue.
The document instructs users to authenticate with an API token on the command line but does not warn that passing secrets as CLI arguments can expose them through shell history, process listings, logs, or CI output. In a quick-start guide for publishing a skill, this omission increases the chance that users mishandle credentials during routine deployment.
The skill documentation is written entirely in Chinese, including headings, instructions, and safety guidance, with no indication that users may choose another language or that the skill is intentionally limited to a Chinese-speaking audience. Under the policy, mandating a specific language without opt-in or justification is a natural-language policy violation.
The documentation explicitly instructs users to place highly sensitive credentials such as Xiaomi account usernames/passwords, device tokens, HomeKit PINs, and optionally Apple ID credentials into TOOLS.md, which is typically a plaintext documentation/configuration file. Storing these secrets in an easily readable file materially increases the risk of credential theft, accidental commit to version control, lateral access to smart home devices, and possible compromise of linked cloud accounts.
The document instructs users to authenticate with an API token via a shell command but does not warn that embedding secrets directly in command lines can expose them through shell history, process listings, screenshots, logs, or shared terminals. Because this is a publishing/authentication workflow, users are likely to copy-paste the example verbatim, increasing the chance of credential leakage and subsequent account compromise.
The document includes a command that executes a home-automation scene ("scene run "回家模式"") and shows successful state changes to physical devices without any safety warning, confirmation step, or indication that this affects real hardware. In a smart-home context, triggering lights, HVAC, or curtains can have real-world consequences, especially if copied into a live environment by a user who assumes it is a harmless test.
The manifest description is entirely in Chinese and provides no indication that users can choose another language or locale. Under the stated policy, forcing a specific language without user opt-in is a natural-language policy violation unless the locale restriction is clearly documented and justified.
The package description is written entirely in Chinese and presents the skill in a single language with no indication that other languages or locales are supported. Under the policy for natural-language violations, forcing a specific language without user opt-in is in scope.
The header comment states this is a HomeKit platform adapter with real API integration, but the core behavior does not perform actual device discovery, state reads, or characteristic writes. The documented intent is contradicted by comments and code in the implementation, especially where control and status functions explicitly say they are simplified placeholders.
This JavaScript file contains comments, errors, and console messages entirely in Chinese, including operational guidance and failure messages. Under the policy rule, forcing a specific language without user opt-in is a natural-language policy violation unless the skill is clearly documented as region-specific, which is not shown here.
The docstring and log messages present connect() as successfully connecting to HomeKit and discovering accessories, yet the method only validates that a PIN exists and then prints success messages. No code uses hap-nodejs APIs to pair, connect, or populate this.accessories, so the stated behavior is contradicted by the implementation.
The public control() method is documented and structured as if it performs real device actions such as turnOn and setBrightness. However, _setCharacteristic() explicitly notes that it is a simplified implementation and only logs the requested change before returning success, which contradicts the apparent intent of real control.
This JavaScript file contains natural-language comments and console messages entirely in Chinese, including setup guidance and runtime status output. Because the file does not indicate that the skill is intentionally China/Chinese-only or provide any language opt-in, it violates the language/locale policy for natural-language content.
The docstring and log messages describe account login ("登录小米账号" / "小米账号登录成功"), which implies authenticating with Xiaomi cloud credentials. However, the code only checks that username and password are present, then calls miio.device({ address, token }) to connect to a local device and does not use this.username or this.password in any authentication flow.
The report content is predominantly in Chinese while also targeting international channels and users, but it does not indicate that users can choose their preferred language or locale. Under the stated policy, forcing a specific language without opt-in can be a natural-language policy issue.
The skill guidance is presented entirely in Chinese, including headings and operational instructions, with no indication that this language choice is optional, user-selected, or intended for a specific locale. The policy requires flagging language or locale constraints when a specific language is effectively forced without opt-in or justification.
All headings, instructions, and warnings are presented in Chinese, and the document does not provide an alternative language option or state that the skill is intended only for a Chinese-speaking region. This can violate language/locale policy when users are not given an opt-in or locale-specific justification.
The user-facing description string forces a specific language/locale in natural-language output. Under the policy, locale constraints should either offer user choice or be clearly documented as intentionally region-specific; this file does neither.
Using caret ranges for dependencies allows newer releases to be installed without explicit review, which weakens build reproducibility and can unexpectedly introduce vulnerable or malicious upstream versions. In a CLI that controls smart-home and IoT devices, dependency compromise could affect local credentials, device control flows, or network requests.
"author": "lvjunjie-byte",
"license": "MIT-0",
"dependencies": {
"commander": "^11.0.0",
"axios": "^1.6.0",
"chalk": "^5.3.0",
"ora": "^7.0.0",
The unpinned axios dependency permits semver-compatible updates to be resolved at install time, reducing supply-chain integrity and making it harder to verify whether a safe version is actually installed. Because axios is commonly used for outbound HTTP requests, compromise or regression here could affect authentication material, API traffic, or remote command flows.
"license": "MIT-0",
"dependencies": {
"commander": "^11.0.0",
"axios": "^1.6.0",
"chalk": "^5.3.0",
"ora": "^7.0.0",
"inquirer": "^9.2.0",
The manifest references axios with a non-exact version while the package family has multiple known advisories, making it impossible to verify from this file whether a vulnerable release will be installed. Given axios' central role in HTTP communication, an affected version could expose requests, credentials, or enable SSRF-like behavior depending on usage in the CLI.
An unpinned chalk dependency introduces unnecessary supply-chain risk because future package resolution may pull in different code than was originally tested. While chalk is typically low-privilege formatting code, the npm execution and import model means a malicious package version could still execute in the CLI context.
"dependencies": {
"commander": "^11.0.0",
"axios": "^1.6.0",
"chalk": "^5.3.0",
"ora": "^7.0.0",
"inquirer": "^9.2.0",
"yaml": "^2.3.0",
No suspicious patterns detected.