hearth

Security checks across malware telemetry and agentic risk

Overview

This homelab health-check skill is mostly coherent, but it deserves Review because it can run configured shell commands on devices and weakens SSH/credential safety while presenting itself as guaranteed read-only.

Install only if you are comfortable with a network-active homelab tool that uses your SSH credentials and bearer tokens. Audit devices.yaml carefully, avoid command probes unless you wrote them yourself, prefer SSH keys and scoped tokens, do not store long-lived secrets in shell profiles, and consider editing the SSH options to keep host-key verification enabled before use.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (13)

Description-Behavior Mismatch

Medium

Confidence: 93% confidence
Finding: The script reads per-app `command` values from configuration and executes them via `hearth_ssh_run` on the target host. That creates a general-purpose remote command execution path inside a skill presented as a read-only health check, so a malicious or tampered config can run arbitrary commands rather than only fixed probes.

Context-Inappropriate Capability

Medium

Confidence: 89% confidence
Finding: This app-check path is effectively a generic remote execution feature because it accepts arbitrary config-supplied shell text and runs it on devices. In the context of a homelab sweep tool, that exceeds the minimally necessary capability for status checking and increases the blast radius if the config file or device definitions are attacker-controlled.

Intent-Code Divergence

Medium

Confidence: 96% confidence
Finding: The helper unconditionally sets StrictHostKeyChecking=no, which disables SSH server identity verification and can silently accept a malicious host during connection. That undermines the claimed read-only behavior because it mutates the client's trust model and enables man-in-the-middle interception of all subsequent health-check commands and results.

Vague Triggers

Medium

Confidence: 91% confidence
Finding: The README explicitly advertises broad natural-language trigger phrases such as "server status", "check all servers", and "how is the lab" for automatic routing. In an agent ecosystem, overly generic triggers can cause unintended invocation of a network-capable skill, which may initiate SSH/HTTP probes against internal infrastructure when the user did not intend to run this tool.

Vague Triggers

Medium

Confidence: 86% confidence
Finding: The trigger phrases are broad enough to match common conversational requests such as 'what's running?' or 'is X up?', which could cause the skill to activate unexpectedly. In this skill, activation leads to shell execution and network probing of multiple configured devices, so an over-broad trigger can cause unintentional scanning and disclosure of host health data.

Vague Triggers

Medium

Confidence: 90% confidence
Finding: The documented OpenClaw trigger phrases are broad, natural-language phrases like 'server status' and 'check all servers' that can easily appear in ordinary conversation. In an agent runtime, this can cause unintended invocation of the skill, leading to unplanned network probing across the user's homelab and disclosure of status information when the user did not explicitly intend to run the tool.

Missing User Warnings

Medium

Confidence: 98% confidence
Finding: The install guide instructs users to export passwords and bearer tokens as environment variables and add those exports to shell startup files so they persist. Persisting long-lived secrets in plaintext shell profiles increases the chance of credential leakage through filesystem exposure, backups, dotfile sync, accidental sharing, process/environment inspection, or reuse by unrelated shells and tools.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The Docker example mounts the user's entire ~/.ssh directory read-only and passes a secret-bearing environment variable into the container, but it does not warn that any process inside the container can use those credentials for outbound authentication. In a security-sensitive context, this increases the blast radius of a compromised or untrusted container image and may expose more keys or secrets than necessary.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The troubleshooting guidance suggests testing SSH with `sshpass -p "$HEARTH_PASS_X" ssh user@host`, which encourages passing credentials on the command line. Even with shell variable expansion, this pattern normalizes insecure secret handling and may expose passwords via process listings, shell history patterns, screenshots, or copied troubleshooting transcripts.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The documentation explicitly recommends `verify_tls: false` for self-signed certificates but does not warn that this disables certificate validation and allows man-in-the-middle interception or spoofing on the LAN. In a health-check tool that may send bearer tokens via `auth_header_env`, this can expose credentials and cause false health results by trusting an attacker-controlled endpoint.

Missing User Warnings

High

Confidence: 95% confidence
Finding: Unlike the baseline SSH health bundle, this code executes arbitrary app-defined commands without any explicit warning that config entries will be run on the device. Because the command text is taken directly from configuration, users may believe they are enabling passive app checks when they are actually authorizing arbitrary shell execution on monitored hosts.

Missing User Warnings

Medium

Confidence: 85% confidence
Finding: The function automatically injects a bearer token from an environment variable into outbound HTTP requests, which can cause sensitive credentials to be sent to unintended endpoints if configuration is wrong or attacker-controlled. In a generic, configuration-driven health-check tool, this increases the risk of token leakage via misconfiguration, malicious URLs, redirects, or probing untrusted services.

Missing User Warnings

Medium

Confidence: 98% confidence
Finding: Disabling SSH host key verification without disclosure is a real security weakness because users are not informed that the tool will trust any presented host key. In a homelab health-check tool that connects to many devices, this increases exposure to spoofed hosts, DNS/IP hijacking, or local network interception while presenting results as if they came from legitimate systems.

VirusTotal

63/63 vendors flagged this skill as clean.

View on VirusTotal