Security audit

hearth

Security checks for vulnerabilities and agentic risk

Overview

This skill is a disclosed homelab health checker that uses SSH and HTTP probes against user-configured devices without evidence of hidden telemetry, destructive actions, or credential theft.

Install only on a bridgehead you control and point it only at devices you own. Prefer a dedicated unprivileged SSH key over ssh-pass, keep HEARTH_SSH_STRICT at accept-new or yes, review ~/.hearth/devices.yaml carefully, and ensure any user-defined command probes are genuinely read-only before allowing an agent to run full sweeps or --watch/cron modes.

A.I.G

Vulnerability Patterns

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
Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
Rogue AgentSelf-Modification, Session Persistence
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (45)

Credential Access

High

Category: Privilege Escalation
Confidence: 90% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Content: Scanner excerpt · CHANGELOG.md (reported line 11)May include surrounding context.
md
## [0.3.0] — 2026-10-05 ### Security - **SSH host-key verification is now ON by default.** `hearth_ssh_opts()` previously set `StrictHostKeyChecking=no`, which — combined with `sshpass` password auth — allowed a password login to a host whose key had changed (a man-in-the-middle exposure). hearth now defaults to `StrictHostKeyChecking=accept-new`: each host's key is pinned on first contact and any later change aborts that device's probe. Host keys are pinned to a **dedicated** `~/.hearth/known_hosts`, kept separate from the user's personal `~/.ssh/known_hosts`. - **New `HEARTH_SSH_STRICT` control** — `accept-new` (default), `yes` (strictest; key must already be known), or `no` (disabled, with a warning printed on every run). `HEARTH_KNOWN_HOSTS` overrides the known_hosts location. - hearth never disables host-key checking silently; `no` is an explicit, warned opt-in only.

Credential Access

High

Category: Privilege Escalation
Confidence: 90% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Content: Scanner excerpt · README.md (reported line 222)May include surrounding context.
md
## [0.3.0] — 2026-10-05 ### Security - **SSH host-key verification is now ON by default.** `hearth_ssh_opts()` previously set `StrictHostKeyChecking=no`, which — combined with `sshpass` password auth — allowed a password login to a host whose key had changed (a man-in-the-middle exposure). hearth now defaults to `StrictHostKeyChecking=accept-new`: each host's key is pinned on first contact and any later change aborts that device's probe. Host keys are pinned to a **dedicated** `~/.hearth/known_hosts`, kept separate from the user's personal `~/.ssh/known_hosts`. - **New `HEARTH_SSH_STRICT` control** — `accept-new` (default), `yes` (strictest; key must already be known), or `no` (disabled, with a warning printed on every run). `HEARTH_KNOWN_HOSTS` overrides the known_hosts location. - hearth never disables host-key checking silently; `no` is an explicit, warned opt-in only.

Credential Access

High

Category: Privilege Escalation
Confidence: 90% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Content: Scanner excerpt · SKILL.md (reported line 45)May include surrounding context.
md
## [0.3.0] — 2026-10-05 ### Security - **SSH host-key verification is now ON by default.** `hearth_ssh_opts()` previously set `StrictHostKeyChecking=no`, which — combined with `sshpass` password auth — allowed a password login to a host whose key had changed (a man-in-the-middle exposure). hearth now defaults to `StrictHostKeyChecking=accept-new`: each host's key is pinned on first contact and any later change aborts that device's probe. Host keys are pinned to a **dedicated** `~/.hearth/known_hosts`, kept separate from the user's personal `~/.ssh/known_hosts`. - **New `HEARTH_SSH_STRICT` control** — `accept-new` (default), `yes` (strictest; key must already be known), or `no` (disabled, with a warning printed on every run). `HEARTH_KNOWN_HOSTS` overrides the known_hosts location. - hearth never disables host-key checking silently; `no` is an explicit, warned opt-in only.

Credential Access

High

Category: Privilege Escalation
Confidence: 90% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Content: Scanner excerpt · SKILL.md (reported line 150)May include surrounding context.
md
## [0.3.0] — 2026-10-05 ### Security - **SSH host-key verification is now ON by default.** `hearth_ssh_opts()` previously set `StrictHostKeyChecking=no`, which — combined with `sshpass` password auth — allowed a password login to a host whose key had changed (a man-in-the-middle exposure). hearth now defaults to `StrictHostKeyChecking=accept-new`: each host's key is pinned on first contact and any later change aborts that device's probe. Host keys are pinned to a **dedicated** `~/.hearth/known_hosts`, kept separate from the user's personal `~/.ssh/known_hosts`. - **New `HEARTH_SSH_STRICT` control** — `accept-new` (default), `yes` (strictest; key must already be known), or `no` (disabled, with a warning printed on every run). `HEARTH_KNOWN_HOSTS` overrides the known_hosts location. - hearth never disables host-key checking silently; `no` is an explicit, warned opt-in only.

Credential Access

High

Category: Privilege Escalation
Confidence: 90% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Content: Scanner excerpt · docs/INSTALL.md (reported line 141)May include surrounding context.
md
## [0.3.0] — 2026-10-05 ### Security - **SSH host-key verification is now ON by default.** `hearth_ssh_opts()` previously set `StrictHostKeyChecking=no`, which — combined with `sshpass` password auth — allowed a password login to a host whose key had changed (a man-in-the-middle exposure). hearth now defaults to `StrictHostKeyChecking=accept-new`: each host's key is pinned on first contact and any later change aborts that device's probe. Host keys are pinned to a **dedicated** `~/.hearth/known_hosts`, kept separate from the user's personal `~/.ssh/known_hosts`. - **New `HEARTH_SSH_STRICT` control** — `accept-new` (default), `yes` (strictest; key must already be known), or `no` (disabled, with a warning printed on every run). `HEARTH_KNOWN_HOSTS` overrides the known_hosts location. - hearth never disables host-key checking silently; `no` is an explicit, warned opt-in only.

Credential Access

High

Category: Privilege Escalation
Confidence: 90% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Content: Scanner excerpt · scripts/lib/ssh.sh (reported line 23)May include surrounding context.
sh
## [0.3.0] — 2026-10-05 ### Security - **SSH host-key verification is now ON by default.** `hearth_ssh_opts()` previously set `StrictHostKeyChecking=no`, which — combined with `sshpass` password auth — allowed a password login to a host whose key had changed (a man-in-the-middle exposure). hearth now defaults to `StrictHostKeyChecking=accept-new`: each host's key is pinned on first contact and any later change aborts that device's probe. Host keys are pinned to a **dedicated** `~/.hearth/known_hosts`, kept separate from the user's personal `~/.ssh/known_hosts`. - **New `HEARTH_SSH_STRICT` control** — `accept-new` (default), `yes` (strictest; key must already be known), or `no` (disabled, with a warning printed on every run). `HEARTH_KNOWN_HOSTS` overrides the known_hosts location. - hearth never disables host-key checking silently; `no` is an explicit, warned opt-in only.

Ae1

High

Category: analysis-evasion
Confidence: 100% confidence
Finding: Referenced artifact was not completely inspected
Content: Scanner excerpt · SKILL.md (reported line 176)May include surrounding context.
md
- `scripts/check-device.sh` — runs the 5-layer probe on one device

Tool Parameter Abuse

High

Category: Tool Misuse
Confidence: 90% confidence
Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Content: Scanner excerpt · docs/INSTALL.md (reported line 192)May include surrounding context.
bash
# Remove the hearth install directory rm -r ~/hearth # Remove your local config and pinned host keys # (back this up first if you may reinstall later)

Tool Parameter Abuse

High

Category: Tool Misuse
Confidence: 90% confidence
Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Content: Scanner excerpt · docs/INSTALL.md (reported line 196)May include surrounding context.
bash
# Remove the hearth install directory rm -r ~/hearth # Remove your local config and pinned host keys # (back this up first if you may reinstall later)

Tool Parameter Abuse

High

Category: Tool Misuse
Confidence: 85% confidence
Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Content: Scanner excerpt · docs/INSTALL.md (reported line 192)May include surrounding context.
bash
# Remove the hearth install directory rm -r ~/hearth # Remove your local config and pinned host keys # (back this up first if you may reinstall later)

Tool Parameter Abuse

High

Category: Tool Misuse
Confidence: 85% confidence
Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
Content: Scanner excerpt · docs/INSTALL.md (reported line 196)May include surrounding context.
Remove your local config and pinned host keys

(back this up first if you may reinstall later)

rm -r ~/.hearth

text

Chaining Abuse

High

Category: Tool Misuse
Confidence: 75% confidence
Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
Content: Scanner excerpt · docs/PLATFORMS.md (reported line 24)May include surrounding context.
md
Just works. No special notes for any modern distro (Debian 11+, Ubuntu 20.04+, Arch, Fedora 35+, RHEL/Rocky/Alma 8+). `sshpass` is in the default repo on Debian/Ubuntu/Arch. On RHEL/Rocky/Alma you may need EPEL (`sudo dnf install epel-release && sudo dnf install sshpass`) or to use SSH keys instead. ## macOS specifics

Credential Access

High

Category: Privilege Escalation
Confidence: 90% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Content: Scanner excerpt · examples/archetypes/linux-systemd.md (reported line 32)May include surrounding context.
yaml
auth: ssh-key user: admin key_path: ~/.ssh/id_ed25519

What the 5 layers will show

Credential Access

High

Category: Privilege Escalation
Confidence: 90% confidence
Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Content: Scanner excerpt · examples/devices.example.yaml (reported line 66)May include surrounding context.
yaml
```yaml auth: ssh-key user: admin key_path: ~/.ssh/id_ed25519 ``` ## What the 5 layers will show

Chaining Abuse

High

Category: Tool Misuse
Confidence: 75% confidence
Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
Content: Scanner excerpt · scripts/lib/probe.sh (reported line 151)May include surrounding context.
sh
result="$name=HTTP $code (expected $expect_code)" fi [ -n "$body" ] && rm -f "$body" echo "$result" }

Session Persistence

Medium

Category: Rogue Agent
Confidence: 80% confidence
Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
Content: Scanner excerpt · CONTRIBUTING.md (reported line 30)May include surrounding context.
md
## Before opening a PR 1. **Privacy first** — never include real IPs, real hostnames, real tokens, or real domain names in code, examples, or commit messages. Use the `192.0.2.0/24` documentation block (RFC 5737) and `example.com` for any sample data. 2. **Read-only invariant** — every probe must be read-only. No `systemctl restart`, no `apt-get install`, no `rm`, no writes to remote hosts beyond `/tmp/.hearth_*` files which are immediately cleaned up. 3. **Honest reporting** — if a layer cannot be probed for a given device type, the output must say so (e.g. "no-systemd (chroot — N/A)"), never silently fake a green result. 4. **Test it** — show that your change works against at least one real device before opening the PR. 5. **Document it** — if you add a new feature or device archetype, update the docs.

Vague Triggers

Medium

Category: Not specified by scanner
Confidence: 95% confidence
Finding: The README explicitly advertises broad natural-language triggers such as 'how's the lab?' and 'check all my servers', which can match ordinary conversation and cause the agent to invoke a network-enumerating skill unexpectedly. In an agent setting, overly broad routing increases the chance of unintended SSH/HTTP probing across many hosts, expanding operational and privacy risk even if the probes are intended to be read-only.
Content: No source excerpt is available for this finding.

Session Persistence

Medium

Category: Rogue Agent
Confidence: 60% confidence
Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
Content: Scanner excerpt · README.md (reported line 129)May include surrounding context.
md
cd hearth # 2. Copy the example config and customise it for your devices mkdir -p ~/.hearth cp examples/devices.example.yaml ~/.hearth/devices.yaml $EDITOR ~/.hearth/devices.yaml

Vague Triggers

Medium

Category: Not specified by scanner
Confidence: 93% confidence
Finding: The OpenClaw trigger description again uses ambiguous homelab phrases without strong scope boundaries, which can cause the skill to activate on loosely related user requests. Because this skill performs broad multi-host connectivity checks, accidental invocation can disclose infrastructure state or generate network activity the user did not clearly intend.
Content: No source excerpt is available for this finding.

Session Persistence

Medium

Category: Rogue Agent
Confidence: 80% confidence
Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
Content: Scanner excerpt · README.md (reported line 216)May include surrounding context.
md
hearth is built to be safe to run from an agent, from cron, or from a shared shell. - **Read-only probes.** hearth runs only non-mutating queries — `uptime`, `free`, `df`, `systemctl is-active`, `curl` (GET). It never restarts a service, installs a package, or writes to a remote host. - **Host-key verification on by default.** SSH probes use `StrictHostKeyChecking=accept-new`: each host's key is pinned on first contact to a dedicated `~/.hearth/known_hosts`, and a later key change aborts that host's probe — the guard that stops a man-in-the-middle from intercepting a password login. Tune with `HEARTH_SSH_STRICT`: - `accept-new` *(default)* — trust-on-first-use, reject changed keys - `yes` — strictest; the key must already be in `known_hosts` (pre-populate it for the hardest posture)

Undeclared Tool Scope

Medium

Category: MCP Least Privilege
Confidence: 88% confidence
Finding: The skill declares shell and environment-variable capabilities but does not define an explicit tool/permission scope. In an agentic environment, that omission weakens policy boundaries and can let the runtime invoke broader shell access than reviewers or users expect. Because the skill performs network probing over SSH/curl, lack of explicit scoping materially increases blast radius if the wrapper scripts or config are abused.
Content: No source excerpt is available for this finding.

Session Persistence

Medium

Category: Rogue Agent
Confidence: 80% confidence
Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
Content: Scanner excerpt · SKILL.md (reported line 114)May include surrounding context.
md
Three things make hearth different from "just SSH and check yourself" or "set up Prometheus": - **Read-only by design.** Never modifies remote state. No `systemctl restart`, no package installs, no writes beyond a per-run temp file. Safe to run from cron, from an LLM agent, from a colleague's shell. Most monitoring tools can't make that promise. - **Honest about what it can't see.** When a layer can't be probed (Windows host with no SSH, chroot with no systemd), hearth says so explicitly — `unmanaged-host (no SSH)`, `no-systemd (chroot — N/A)`. It doesn't fake a green result. You always know whether a green is real or just unmeasured. - **Zero install on remote hosts.** No agent on every box. No `node_exporter`. No daemon. Just SSH from one bridgehead. If you can SSH to a host, hearth can probe it.

Session Persistence

Medium

Category: Rogue Agent
Confidence: 80% confidence
Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
Content: Scanner excerpt · SKILL.md (reported line 226)May include surrounding context.
md
Three things make hearth different from "just SSH and check yourself" or "set up Prometheus": - **Read-only by design.** Never modifies remote state. No `systemctl restart`, no package installs, no writes beyond a per-run temp file. Safe to run from cron, from an LLM agent, from a colleague's shell. Most monitoring tools can't make that promise. - **Honest about what it can't see.** When a layer can't be probed (Windows host with no SSH, chroot with no systemd), hearth says so explicitly — `unmanaged-host (no SSH)`, `no-systemd (chroot — N/A)`. It doesn't fake a green result. You always know whether a green is real or just unmeasured. - **Zero install on remote hosts.** No agent on every box. No `node_exporter`. No daemon. Just SSH from one bridgehead. If you can SSH to a host, hearth can probe it.

Session Persistence

Medium

Category: Rogue Agent
Confidence: 60% confidence
Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
Content: Scanner excerpt · SKILL.md (reported line 220)May include surrounding context.
md
## Triggers requiring extra care - **"restart X" / "kill X" / "deploy X" / "install X"** — hearth is read-only. If the user asks for write actions, do NOT use hearth — explain that hearth doesn't modify remote state and ask if they want to do that another way. - **"add a new device"** — direct the user to edit `~/.hearth/devices.yaml`. Reference `examples/devices.example.yaml` and `docs/CONFIG.md` in the project for schema. - **"why is X down?"** — first run `./scripts/sweep.sh --device <X>` to confirm the failure mode, then suggest investigation paths based on which layer failed (L1 = network, L4 = services, L5 = app).

External Transmission

Medium

Category: Data Exfiltration
Confidence: 60% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Content: Scanner excerpt · docs/INSTALL.md (reported line 27)May include surrounding context.
Install the prerequisites (run by you, once):

bash
sudo apt-get install -y bash openssh-client sshpass curl python3 jq

Then clone and configure:

Static analysis

No suspicious patterns detected.

Overview

A.I.G

SkillSpector

Credential Access

Credential Access

Credential Access

Credential Access

Credential Access

Credential Access

Ae1

Tool Parameter Abuse

Tool Parameter Abuse

Tool Parameter Abuse

Tool Parameter Abuse

Remove your local config and pinned host keys

(back this up first if you may reinstall later)

Chaining Abuse

Credential Access

What the 5 layers will show

Credential Access

Chaining Abuse

Session Persistence

Vague Triggers

Session Persistence

Vague Triggers

Session Persistence

Undeclared Tool Scope

Session Persistence

Session Persistence

Session Persistence

External Transmission

Static analysis