Back to skill

Security audit

Tuya Smart Home

Security checks for vulnerabilities and agentic risk

Overview

The skill appears purpose-built for Tuya smart-home control, but it handles powerful device credentials and physical device commands with weak warnings and unsafe command-line secret handling.

Review before installing. Use this only for Tuya devices and networks you own or administer, avoid putting real access secrets or local keys directly in shell commands, do not share cloud info output because it may include local_key values, and consider pinning dependencies in a virtual environment before use.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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 (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:11
Finding
Unpinned Third-Party Dependencies Create a Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md:11-14` **Vulnerability Type**: Unpinned and integrity-unverified Python dependencies **Risk Level**: Medium **Vulnerable Code:** ```markdown ## Dependencies ```bash pip3 install tinytuya tuya-connector-python ``` ``` ### Technical Analysis The installation instructions retrieve the latest available versions of `tinytuya`, `tuya-connector-python`, and their transitive dependencies from pip's configured package index. No exact versions, cryptographic hashes, lockfile, or trusted index configuration is provided. Consequently, the code installed by this command can change after the Skill has been reviewed. A compromised package maintainer account, malicious replacement release, dependency confusion condition, compromised transitive dependency, or compromised package index could cause arbitrary attacker-controlled Python code to be installed or imported. The audit found no evidence that the currently named packages are malicious. The vulnerability is the absence of version and integrity controls around executable third-party dependencies. ### Attack Path 1. An attacker compromises one of the named packages, a transitive dependency, a maintainer account, or an applicable package index. 2. The attacker publishes a malicious release that satisfies the unrestricted dependency request. 3. A user follows the documented `pip3 install` command. 4. pip resolves and downloads the attacker-controlled release. 5. Malicious code executes during package installation or when `tuya_control.py` or `tuya_scan.py` imports the package. 6. The malicious dependency operates with the privileges and environment access of the user running pip or the Skill. ### Impact Assessment Successful exploitation could provide arbitrary code execution under the installing or executing user's account. Depending on that account's privileges, the attacker could access local files, environment varia ...[truncated 403 chars]
Remediation
## Remediation Suggestions 1. Provide a reviewed dependency lockfile containing exact versions for all direct and transitive dependencies. 2. Require cryptographic hashes, for example through a generated `requirements.txt` used with: ```bash python3 -m pip install --require-hashes -r requirements.txt ``` 3. Install dependencies in a dedicated, non-privileged virtual environment rather than globally or as root. 4. Configure an explicitly trusted package index or an internally controlled package mirror. 5. Add automated dependency vulnerability, provenance, and update review checks. 6. Test and review dependency upgrades before changing pinned versions. 7. Document the supported Python and package versions to make installations reproducible.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/tuya_control.py:109
Finding
Tuya Cloud Secrets and Device Keys Are Exposed Through Command-Line Arguments## Vulnerability Details **File Location**: `scripts/tuya_control.py:109-116`; documented usage in `SKILL.md:43-83` **Vulnerability Type**: Sensitive credentials passed through process arguments **Risk Level**: Medium **Vulnerable Code:** ```python # Cloud options parser.add_argument('--access-id', help='Tuya Access ID (cloud mode)') parser.add_argument('--access-secret', help='Tuya Access Secret (cloud mode)') parser.add_argument('--region', default='cn', choices=['cn', 'us', 'eu', 'in'], help='Data center region') # Local options parser.add_argument('--ip', help='Device IP (local mode)') parser.add_argument('--local-key', help='Device local key (local mode)') parser.add_argument('--version', type=float, default=3.4, help='Protocol version (default: 3.4)') ``` The corresponding documented invocation patterns include: ```bash python3 scripts/tuya_control.py --mode cloud --action info \ --device-id DEVICE_ID \ --access-id ACCESS_ID --access-secret ACCESS_SECRET --region cn python3 scripts/tuya_control.py --mode local --action status \ --device-id DEVICE_ID --ip IP --local-key KEY ``` ### Technical Analysis The interface requires users to place the Tuya cloud access secret or Tuya device local encryption key directly in the command line. Command-line arguments are not an appropriate secret transport mechanism because they can be retained or exposed outside the program. Depending on the operating environment, real credential values may become available through: - Shell history files. - Process inspection interfaces and monitoring tools. - Process accounting or endpoint telemetry. - CI/CD job definitions and build logs. - Automation transcripts, terminal recordings, and support bundles. - Agent or orchestration logs that record invoked commands. The script does not intentionally print these secrets, and no hardcoded credential was found. The exposure arises from the documented and implem ...[truncated 1752 chars]
Remediation
## Remediation Suggestions 1. Remove command-line options for secret values, or retain them only as explicitly discouraged legacy options. 2. Support protected environment variables such as `TUYA_ACCESS_SECRET` and `TUYA_LOCAL_KEY`, while ensuring that application logs never dump the environment. 3. Prefer an operating-system secret store, dedicated secret manager, or configuration file with restrictive permissions. 4. Add interactive secret entry through `getpass.getpass()` when no protected secret source is configured. 5. Keep non-secret identifiers, such as device IDs and regions, separate from secret material. 6. Update every command example so that no secret value appears in the command line. 7. Add explicit redaction for secrets in exceptions, diagnostic output, telemetry, and debug logging. 8. Document credential rotation procedures and advise existing users to rotate credentials if real values may already exist in shell histories or CI logs. 9. Apply least-privilege Tuya project permissions, API restrictions, and IP allowlisting where available to limit the consequences of credential disclosure.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (4)

Credential Access

High
Category
Privilege Escalation
Content
# Cloud options
    parser.add_argument('--access-id', help='Tuya Access ID (cloud mode)')
    parser.add_argument('--access-secret', help='Tuya Access Secret (cloud mode)')
    parser.add_argument('--region', default='cn', choices=['cn', 'us', 'eu', 'in'], help='Data center region')

    # Local options
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The documentation explicitly highlights that `GET /v1.0/devices/{device_id}` returns a `local_key`, then later explains that this key can be used for direct local control that bypasses cloud restrictions. A `local_key` is effectively a device secret; exposing how to retrieve and use it without any secrecy, storage, or disclosure warning increases the risk that downstream agents or users will log, leak, or mishandle a credential that enables unauthorized device access.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The local control section explains that `device_id`, device IP, protocol version, and especially `local_key` are sufficient to connect and issue commands directly to devices over the LAN. Because the skill controls real-world smart-home devices including feeders, plugs, lights, and curtains, omission of warnings about credential sensitivity and direct control capability materially increases the chance of unsafe or unauthorized actuation.

Missing User Warnings

Low
Confidence
89% confidence
Finding
The network scan example encourages probing the local network and notes that it returns device metadata such as identifiers, product keys, versions, and IPs, but provides no caution about authorization or privacy. While scanning is less severe than exposing a secret directly, in this smart-home context it can facilitate device enumeration and follow-on misuse when combined with other data like `local_key`.

Static analysis

No suspicious patterns detected.