Skillv0.1.2

ClawScan security

Octodns · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousMar 11, 2026, 12:41 AM

Verdict: suspicious
Confidence: high
Model: gpt-5-mini
Summary: The skill's stated metadata omits required credentials and there are scripts that read/write local credential files (including a hard-coded developer path) and run automated syncs; these mismatches and hard-coded paths are inconsistent and warrant caution.
Guidance: Do not install blindly. Key concerns: (1) The registry metadata claims no credentials required, but the skill expects provider API keys (easyDNS, AWS, Cloudflare, etc.) and credential JSON files in a local .credentials directory — verify where you will store these and whether you want this skill to access them. (2) Several scripts use a hard-coded path (/Users/markjr/clawd/.credentials) and load credentials from JSON files — inspect and edit these scripts before running; change any absolute paths to a safe location you control. (3) The skill's automation (cron/webhook/CI examples) invokes sync operations that can DELETE many DNS records if the YAML lacks them — always run dump + preview and never run scripts/sync.sh --doit on production until you've confirmed the workflow. (4) The webhook example runs a Flask server that will apply updates it receives; do not expose that to untrusted networks. (5) If you proceed, run everything in an isolated environment, review and edit scripts (especially load_credentials.sh and setup.sh), and test on non-production zones only. If you need help auditing/locking down the credential paths and disabling automatic --doit behavior, get those changes applied before granting the skill any provider credentials.

Review Dimensions

Purpose & Capability: concernThe skill is legitimately a DNS management wrapper and therefore needs DNS provider credentials (easyDNS, AWS/Route53, Cloudflare, etc.). However, the registry metadata declares no required environment variables or primary credential while the SKILL.md and scripts repeatedly expect EASYDNS_*, AWS_*, CLOUDFLARE_TOKEN, or credential JSON files. That discrepancy between declared requirements and actual needs is incoherent and risks surprise credential access when installed.
Instruction Scope: concernSKILL.md and included scripts instruct the agent to create/modify local config files, load credentials from a .credentials directory (or environment variables), run octodns commands that can DELETE records, and even provide examples that start a Flask webhook that will accept incoming requests and run syncs. The instructions therefore include file I/O of secrets, network listeners, and automation that can make destructive changes — all within the skill. The README/SAFETY emphasize the destructive risk, but the automation examples (webhook/cron/CI) and the scripts’ behavior exceed a minimal, read-only scope.
Install Mechanism: noteThis is instruction-plus-scripts (no platform install spec). The included install.sh creates a Python venv and pip-installs octodns and a provider package (octodns-easydns). Installing via pip into a venv is expected for this project and not unusual, but because the package will run local code (scripts) it will write files and may run network requests to provider APIs during operation.
Credentials: concernAlthough the skill metadata lists no required env vars, the code expects and loads many secrets: EASYDNS_TOKEN, EASYDNS_API_KEY, EASYDNS_PORTFOLIO, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, CLOUDFLARE_TOKEN, and provider-specific credential JSON files under a .credentials directory. There are multiple mechanisms to load credentials (env vars, .credentials JSON, and a load_credentials.sh which even hard-codes a developer home path). Requesting broad provider credentials without declaring them in metadata is disproportionate and surprising.
Persistence & Privilege: noteThe skill does not set always:true. It writes/reads local agent config (.agent-config.json) and credential directories (.credentials) and offers scripts to create them via setup.sh. That behavior is normal for a tool that needs local credentials, but several scripts use a hard-coded developer path (/Users/markjr/clawd/.credentials) which is sloppy and suspicious — it may fail on other systems or inadvertently point to a captured path from the developer. Autonomous invocation is enabled (default) — combined with the undeclared credentials this increases blast radius, so exercise caution.