ClawHub
Back to skill

Security audit

Wyze Sensors

Security checks for vulnerabilities and agentic risk

Overview

This skill coherently reads Wyze sensor status, but users should understand it uses Wyze credentials, cached login state, and an unofficial npm dependency.

Install only if you are comfortable giving this skill access to Wyze API credentials and cached Wyze login state. Keep the WYZE_ENV file limited to Wyze variables, protect the token directory permissions, and prefer a pinned dependency or lockfile before relying on it in a sensitive home environment.

A.I.G

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
scripts/package.json:5
Finding

Unpinned Third-Party Dependency Creates a Supply-Chain Risk

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:27 and scripts/package.json:5-7
Vulnerability Type: Unpinned and mutable third-party dependency
Risk Level: Medium

The installation instructions retrieve wyze-node without specifying a version:

text
npm install --prefix "{baseDir}/scripts" wyze-node

The package manifest also permits npm to select a newer compatible release:

json
"dependencies": {
  "wyze-node": "^2.12.2"
}

No dependency lockfile was present in the audited project.

Technical Analysis

The documented installation command resolves the latest available version of wyze-node, while the caret range in package.json allows compatible releases newer than 2.12.2. Without a committed lockfile, the exact package version and transitive dependency graph installed by users can change after the skill has been reviewed.

npm packages and their transitive dependencies may execute lifecycle scripts during installation. A compromised maintainer account, malicious package release, or compromised transitive dependency could therefore introduce code that executes under the installing user's account. At runtime, the dependency also receives the Wyze email address, key ID, and API key and operates in the cached-token directory, making dependency integrity particularly security-sensitive.

This audit found no evidence that the currently declared wyze-node package is malicious. The finding concerns the mutable and insufficiently reproducible dependency installation process.

Attack Path

  1. An attacker compromises wyze-node, one of its transitive dependencies, or the associated package-publishing account.
  2. The attacker publishes a release accepted by the unversioned setup command or the ^2.12.2 version range.
  3. A user follows the documented setup procedure or performs a fresh dependency installation.
  4. npm downloads the altered dependency graph and may execute attacker ...[truncated 1171 chars]
Remediation
View remediation

Remediation Suggestions

  1. Replace the caret range with an exact, reviewed package version:
    json
    "dependencies": {
  "wyze-node": "2.12.2"
}
  2. Generate and commit a package-lock.json so direct and transitive dependency versions and integrity hashes are reproducible.
  3. Change the documented installation workflow to use npm ci against the committed lockfile rather than installing an unconstrained package by name.
  4. Review dependency changes before updating the lockfile, including package ownership, release provenance, lifecycle scripts, and newly introduced transitive dependencies.
  5. If dependency lifecycle scripts are not required, install with npm ci --ignore-scripts; otherwise, explicitly audit all required lifecycle scripts.
  6. Run installation and the sensor client under a dedicated, least-privileged account with access limited to the required Wyze credential and token files.
  7. Restrict credential and token file permissions to the owning user and use Wyze credentials with the minimum capabilities required for sensor retrieval.
  8. Add automated dependency scanning and lockfile integrity checks to the release process.

SkillSpector

Vulnerability Patterns
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (3)

Undeclared Tool Scope

Medium
Category
MCP Least Privilege
Confidence
89% confidence
Finding

The skill explicitly depends on environment-based secrets (WYZE_EMAIL, WYZE_KEY_ID, WYZE_API_KEY, WYZE_ENV) and cached authentication tokens, but it does not declare any explicit tool scope or permissions boundary for env access. That creates a real least-privilege and transparency issue: an agent or runtime may grant broader secret/env access than users expect, increasing the chance of credential exposure or misuse if the skill is invoked in the wrong context.

Content

No source excerpt is available for this finding.

Unpinned Dependencies

Low
Category
Supply Chain
Confidence
95% confidence
Finding

The dependency uses a caret range (^2.12.2), which allows new compatible versions to be pulled in without explicit review. This creates supply-chain risk because a compromised upstream release or breaking behavioral change could be introduced into the skill at install time, and this skill depends on an unofficial API client that may have less rigorous maintenance and security assurance.

Content

Scanner excerpt · scripts/package.json (reported line 6)May include surrounding context.

json
"private": true,
  "description": "Runtime dependency for the Wyze sensors OpenClaw skill",
  "dependencies": {
    "wyze-node": "^2.12.2"
  }
}

Context-Inappropriate Capability

Low
Category
Not specified by scanner
Confidence
81% confidence
Finding

The manifest describes a read-only skill for reading Wyze sensor states, but this code additionally loads arbitrary uppercase variables from a local env file into process.env. While authentication is needed to reach the Wyze API, directly ingesting local secret material is a broader capability than the user-facing purpose suggests and is not mentioned in the manifest description.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.