ClawHub
Back to skill

Security audit

Homeassistant

Security checks for vulnerabilities and agentic risk

Overview

This Home Assistant skill is purpose-aligned, but it needs review because it handles a durable home-control token insecurely and allows broad physical device control without clear safety boundaries.

Before installing, assume the Home Assistant token can control everything allowed by that HA account. Use a dedicated least-privilege account if possible, avoid pasting the token directly into shell commands, keep any config file out of source control and readable only by your user, and require explicit confirmation before locks, scripts, covers, or climate devices are controlled. Rotate the token if it has already been entered into shell history or committed anywhere.

A.I.G

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:16
Finding

Long-Lived Home Assistant Token Exposed Through Command-Line Arguments

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:16-24
Additional Locations: README.md:13-17, README.md:35-40
Vulnerability Type: Exposure of credentials through process arguments and shell history
Risk Level: High

Vulnerable Code Snippet

markdown
### Configuration (One-Command)

```bash
# Run this to configure
ha-cli setup <HA_URL> <TOKEN>

# Example:
ha-cli setup 192.168.1.100 your_long_lived_token_here
text

The same insecure invocation pattern is presented in `README.md`:

```markdown
# One-command setup
ha-cli setup 192.168.1.100 your_long_lived_token

Technical Analysis

The documented setup procedure requires the user to supply a long-lived Home Assistant access token as a command-line argument. Command-line secrets can be exposed through:

  • Shell history files.
  • Process listings and process-monitoring utilities.
  • Terminal session recording.
  • System command auditing.
  • Diagnostic logs or support bundles.
  • Automation logs that echo executed commands.

A Home Assistant long-lived access token is a bearer credential. Anyone who obtains it can authenticate without possessing an additional secret for as long as the token remains valid. The actual ha-cli executable is absent from the audited package, so its implementation and any attempted argument redaction could not be verified. Nevertheless, the documented invocation itself creates exposure through mechanisms outside the executable.

Attack Path

  1. A user follows the documented setup command and places the long-lived token directly on the command line.
  2. The shell records the complete command in its history, or the argument is captured by process monitoring, terminal logging, or command auditing.
  3. An attacker with access to the affected local account, history file, monitoring output, backup, or log store retrieves the token.
  4. The attacker identifies the Home Assistant endpoint from the same command, configuration, or local network disc ...[truncated 875 chars]
Remediation
View remediation

Remediation Suggestions

  • Do not accept access tokens as ordinary command-line arguments.
  • Prompt for the token interactively using a no-echo input mechanism.
  • Alternatively, accept the token through protected standard input or retrieve it directly from an operating-system credential manager.
  • If environment-variable input is supported, clearly warn that environment variables may be exposed through debugging, subprocess inheritance, crash reports, and misconfigured process inspection.
  • Ensure the CLI never prints, logs, or includes the token in error messages.
  • Redact credentials from diagnostics and structured logs.
  • Update every setup example to use a secure workflow, such as:
bash
ha-cli setup --url http://homeassistant.local:8123
# The CLI then prompts for the token without echoing it.
  • Instruct existing users to remove exposed commands from shell history and revoke and replace any token previously entered on the command line.
  • Use a dedicated Home Assistant account and token with the minimum permissions needed for the intended devices and operations.

T09 · Insecure Skill Coding Practices

Error
Location
README.md:3
Finding

Long-Lived Home Assistant Credential Stored in Plaintext Configuration

Content
View full analysis

Vulnerability Details

File Location: README.md:3-8
Additional Locations: README.md:35-42, config.json:1-4
Vulnerability Type: Plaintext storage of a persistent bearer credential
Risk Level: High

Vulnerable Code Snippet

The README explicitly documents automatic credential storage:

markdown
## Features

- **One-command setup**: `ha-cli setup <url> <token>`
- **Natural commands**: `ha-cli on living room` or `ha-cli living room on`
- **Smart fuzzy matching**: "bed" finds "Bedroom Light", "Bedroom AC"
- **Auto-config save**: Credentials stored in config.json

It further states:

markdown
### 2. Configure

```bash
# Replace with your HA IP and token
ha-cli setup 192.168.1.100 your_token_here

That's it! Configuration is saved automatically.

text

The supplied configuration schema provides a token field:

```json
{
  "url": "http://homeassistant.local:8123",
  "token": ""
}

The audited config.json does not contain a real token. The vulnerability is the documented storage design: a long-lived bearer token is saved in an ordinary JSON configuration file without any documented access-control, encryption, or credential-store protection.

Technical Analysis

Home Assistant long-lived access tokens are reusable bearer credentials. Storing such a token directly in config.json makes its confidentiality dependent entirely on file-system access controls and handling practices.

The documentation does not specify:

  • Owner-only file permissions.
  • Storage outside the project or source tree.
  • Exclusion from version control and backups.
  • Encryption at rest.
  • Use of an operating-system keychain or secret manager.
  • Token redaction from logs or diagnostics.

Because the configuration file is located in the documented project layout, it may be accidentally committed, archived, copied into support bundles, included in backups, exposed through file-sharing tools, or read by other local users and processes. The m ...[truncated 1571 chars]

Remediation
View remediation

Remediation Suggestions

  • Store long-lived tokens in an operating-system credential facility such as macOS Keychain, Windows Credential Manager, or a Linux Secret Service implementation.
  • Keep only a non-sensitive credential reference and the Home Assistant URL in config.json.
  • If file-based secret storage is unavoidable:
    • Store the secret outside the project and source tree.
    • Create the file with owner-only permissions from the outset, such as mode 0600 on POSIX systems.
    • Verify ownership and permissions before every read.
    • Refuse to operate if the credential file is accessible to other users.
    • Use atomic creation that prevents symlink and race-condition attacks.
    • Exclude the file from version control, cloud synchronization, diagnostics, and ordinary backups.
  • Add config.json or the actual secret-bearing configuration path to .gitignore, while distributing a separate token-free example file.
  • Never serialize the token into logs, exceptions, status output, telemetry, or support bundles.
  • Support token revocation and replacement, and document a rotation procedure.
  • Recommend a dedicated least-privilege Home Assistant account rather than a broadly privileged administrator token.
  • Clearly distinguish non-sensitive configuration from secrets in both the documentation and project layout.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (6)

Credential Access

High
Category
Privilege Escalation
Confidence
70% confidence
Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · README.md (reported line 36)May include surrounding context.

md
1. Open Home Assistant Web UI
2. Click your username (Profile)
3. Scroll to "Long-Lived Access Tokens"
4. Click "Create Token"
5. Copy the token

Credential Access

High
Category
Privilege Escalation
Confidence
70% confidence
Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · README.md (reported line 32)May include surrounding context.

md
### Prerequisites

1. Home Assistant running on local network
2. Long-Lived Access Token from HA Profile page

### Configuration (One-Command)

Credential Access

High
Category
Privilege Escalation
Confidence
70% confidence
Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · SKILL.md (reported line 16)May include surrounding context.

md
### Prerequisites

1. Home Assistant running on local network
2. Long-Lived Access Token from HA Profile page

### Configuration (One-Command)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The README explicitly advertises automatic saving of Home Assistant credentials in a local config.json file but gives no warning about secure storage, file permissions, encryption, or exclusion from source control. Long-lived access tokens provide durable API access to a home automation system, so insecure local persistence materially increases the risk of credential theft and subsequent unauthorized control of devices.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
89% confidence
Finding

The skill description and usage language are broad enough that an agent could infer permission to control a wide range of physical devices without clear user-confirmation boundaries. In a home automation context, ambiguous activation can lead to unintended actions affecting locks, climate, power, or other safety-relevant devices.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The documentation instructs users to supply a long-lived Home Assistant token via command line or environment variables but gives no warning about sensitive credential handling. Tokens passed this way may be exposed through shell history, process listings, logs, or insecure local config storage, enabling unauthorized control of the home automation system.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.