Is logancyang/headless-vault-cli safe?
https://github.com/openclaw/skills/tree/main/skills/logancyang/headless-vault-cli
headless-vault-cli is an instruction-only SSH vault wrapper with no malicious code, no prompt injection payloads, no unauthorized exfiltration channels, and a clean installation that makes only expected connections to GitHub. Its security model is architecturally sound — SSH forced-command restrictions and vaultctl path sandboxing provide meaningful containment — but the guarantee depends entirely on the user correctly configuring authorized_keys, and vault note content read by the agent creates an indirect prompt injection surface when notes are sourced from third-party web content. No canary files were exfiltrated and no unexpected network connections were made.
Category Scores
Findings (7)
HIGH Security guarantee depends on correct SSH forced-command configuration -20 ▶
The skill's entire security boundary relies on the user adding the VPS public key to ~/.ssh/authorized_keys with a forced-command wrapper that restricts execution to vaultctl only. This is a one-time manual user operation with no automated enforcement or verification. If the user adds the key without the forced-command (a common SSH mistake), the VPS-side agent obtains an unrestricted interactive shell on the user's local computer, enabling arbitrary command execution, file system access, and lateral movement. The SKILL.md documents this requirement clearly but cannot enforce it.
MEDIUM Vault content is an indirect prompt injection surface via third-party note sources -15 ▶
The skill's Example 4 workflow explicitly demonstrates reading external URLs from a source note and writing their content into new vault notes. When those notes are later read back by the agent, third-party content becomes part of the agent's context. A malicious website could embed prompt injection payloads in its content that, when saved to the vault and subsequently read by the agent, could override agent behavior, trigger unexpected tool calls, or exfiltrate other vault data via co-installed skills.
LOW tree --all flag exposes non-markdown filenames in vault directory -8 ▶
The SKILL.md documents and vault.sh implements the --all flag for vaultctl tree, which lists all files regardless of extension — not just .md files. The actual exposure depends on vaultctl's sandboxing of VAULT_ROOT, but filenames of sensitive non-markdown content (PDFs, config files, certificates) stored in the vault directory could be enumerated. This widens the information surface beyond the intended markdown-notes scope.
LOW Unknown-command error handler interpolates unsanitized argument into JSON output -5 ▶
In vault.sh, the catch-all case constructs a JSON error string by directly interpolating $cmd via shell quote-escaping. If $cmd contains double-quote characters, backslashes, or newlines, the resulting JSON will be malformed. While vault.sh is invoked by the agent (not by untrusted end users directly), a malformed JSON error response could confuse the agent's parsing logic or in edge cases trigger unexpected behavior downstream.
LOW VAULT_SSH_HOST environment variable can redirect SSH connections -5 ▶
The skill accepts VAULT_SSH_HOST as a configurable environment variable defaulting to localhost. If an attacker can influence the agent's environment (e.g., through a compromised co-installed skill that manipulates env vars, or through a misconfigured deployment that exposes env var control to users), the SSH connection could be redirected to an attacker-controlled host. This would allow the attacker to intercept vault operations or return fabricated note content to the agent.
INFO Pre-existing Ubuntu update server connections are not skill-related 0 ▶
Network connections to Canonical/Ubuntu servers (185.125.188.57:443, 185.125.190.18:443) were already ESTAB before skill installation began and are attributable to Ubuntu's background update-notifier or unattended-upgrades services. These are absent from the AFTER connection diff because the monitoring window ended, not because the skill removed them.
INFO Canary file access events attributed to monitoring infrastructure baseline checks 0 ▶
All six credential canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) show OPEN+ACCESS events at timestamps 1771937122.803 (before git clone at 1771937128) and 1771937146.224 (post-install). The pre-clone accesses are definitively from monitoring setup. The post-install accesses are consistent with Oathe's canary integrity verification scan. vault.sh was never invoked during testing (instruction-only skill with no vault commands executed). Monitoring confirms all files intact.