Is acastellana/skill-publisher-claw-skill safe?
https://github.com/openclaw/skills/tree/main/skills/acastellana/skill-publisher-claw-skill
skill-publisher-claw-skill is a legitimate skill publication toolkit with no prompt injection, hidden instructions, or credential harvesting code in its content. The primary risk profile comes from its bundled shell scripts, particularly publish.sh (which performs git add -A and remote push) and fix.sh (which modifies files in-place without backups), which could cause serious unintended consequences if an agent runs them autonomously outside an isolated skill directory. All honeypot canary files remained intact with no exfiltration detected; the credential file access events in monitoring are temporally attributed to the audit framework's own honeypot setup and verification operations rather than the skill.
Category Scores
Findings (8)
HIGH publish.sh Performs Unguarded 'git add -A' with Remote Push -20 ▶
publish.sh stages all files with 'git add -A' and pushes to the configured remote. If an agent runs this script in a user's working repository (rather than an isolated skill directory), it could commit and push sensitive files such as .env, private keys, or AWS credentials to a public GitHub repository. The script accepts a --force flag that bypasses all confirmation prompts.
HIGH Destructive Git History Rewrite Included as Working Example -15 ▶
Both SKILL.md and fix.sh include 'git filter-branch --force --index-filter' as a documented, executable command for removing sensitive files from git history. This operation is irreversible without careful coordination and can permanently destroy commit history if run incorrectly or on the wrong repository.
MEDIUM All Major Credential File Categories Accessed During Audit Period -22 ▶
During the monitoring window, all six major credential file categories were opened and read: .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCloud application_default_credentials.json. File contents remained intact with no exfiltration detected. The first access batch (1771905884) predates the git clone operation (1771905890) by 6 seconds, indicating the audit framework was planting honeypot files. A second batch at 1771905907 aligns with post-analysis integrity verification. Attribution to audit infrastructure vs skill activity is high confidence but not certain.
MEDIUM validate-links.sh Makes Outbound curl Requests to Extracted URLs -10 ▶
validate-links.sh extracts all URLs from skill markdown files and makes outbound HTTP requests via curl to validate them. While URL content originates from documentation, this creates a potential covert channel: a maliciously crafted skill could include URLs with data-encoded parameters that exfiltrate information when the link validator runs.
MEDIUM fix.sh Applies In-Place File Modifications Without Backups -8 ▶
fix.sh uses 'sed -i' to modify markdown files in place — replacing hardcoded paths, personal emails, and trailing whitespace — without creating backups. The --auto flag applies all changes non-interactively. Applied to the wrong directory, this could silently corrupt user files with no recovery path.
LOW Implicit Request for Shell Execution Authority -8 ▶
SKILL.md's workflow instructions direct the agent to invoke shell scripts (./audit.sh, ./fix.sh, ./publish.sh) as standard steps before publishing any skill. This implicitly requires the agent to have and use shell execution permissions, which may not be appropriate in restricted or read-only agent contexts.
LOW Security Scan Patterns Could Locate Real Credentials If Mis-Scoped -8 ▶
The grep patterns documented in SKILL.md for finding secrets (api_key, secret, password, token, bearer, auth; common key prefixes sk-, ghp_, xai-) are intended for scanning skill .md files. An agent interpreting these instructions broadly could run them against parent directories containing real credentials, effectively performing credential enumeration.
INFO Clean Network Profile — Expected Infrastructure Only 0 ▶
All outbound connections during the full install and analysis cycle were to expected hosts. GitHub was contacted for the sparse git clone. Ubuntu/Canonical servers handled system-level operations. No third-party analytics, telemetry, or unexpected endpoints were contacted.