Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
Auto-Claw
v1.0.0Autonomously monitors and optimizes WordPress sites with SEO fixes, performance audits, A/B testing, security, and competitor tracking.
⭐ 0· 60·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
Functionality in the bundle (src/wordpress.py, seo, performance, ab_tester, vault/pipeline/audit, CLI, demos, cron scripts) aligns with the stated purpose of managing and optimizing WordPress sites. However the registry metadata claims no required env vars/configs while the code and SKILL.md clearly expect configuration (VAULT_* env vars, WP_SITES, web-root paths, and optional ClawhHub token). That mismatch is unexpected and should be clarified.
Instruction Scope
SKILL.md instructs cloning a repo and running python3 cli.py full-audit and python3 cli.py monitor --continuous, and the demo/quickref recommend cron jobs and status scripts. The CLI and many source files include code that can read site HTML, SSH/WD access (WP-CLI), run WP-CLI fixes, install plugins, and write files. The instructions therefore authorize wide filesystem and network actions (including continuous autonomous monitoring and scheduled tasks) which are consistent with the purpose but very powerful — ensure approval gating and audit behavior are enforced in practice.
Install Mechanism
There is no formal install spec in registry (instruction-only), but the skill bundle includes an install.sh, scripts, and many code files. That is not necessarily malicious, but the presence of install scripts and cron recommendations means the package can modify the host environment if executed — review install.sh and any shell scripts before running. The SKILL.md clone URL is a placeholder (http://github.com/YOUR_ORG/auto-company) and some docs reference npx, a package.json and pyproject — multiple ways to install/run exist but none are declared in metadata.
Credentials
Registry metadata declares no required environment variables or config paths, but the code reads and depends on environment variables and secrets (examples: VAULT_ENABLED, VAULT_URL, VAULT_TOKEN, WP_SITES, and a ClawhHub `--token` mention). The config module explicitly looks for VAULT_TOKEN and WP_SITES. Asking for Vault tokens or SSH/web-root access would be proportionate to the claimed capabilities, but the metadata should declare these. The mismatch increases the chance of accidental credential exposure or misconfiguration.
Persistence & Privilege
The skill does not request always:true, but instructions and demo scripts encourage running a persistent monitor (python3 cli.py monitor --continuous) and installing cron entries (logs/audit-daily.sh). If run on a host, this creates a persistent agent that can change files and schedule jobs. That is expected for this kind of tool, but it raises operational risk — ensure the Gate pipeline truly blocks destructive operations and audit logging is enabled and reviewed.
What to consider before installing
This package contains a complete toolchain that can modify WordPress files, install plugins, run WP-CLI, create cron jobs and run continuous monitoring. Before installing or running it:
- Do not run install.sh or monitor/demo scripts on production. Test inside an isolated staging VM or container.
- Inspect install.sh, logs/*.sh and all scripts for subprocess calls and network endpoints; search for subprocess/exec/popen usage.
- Confirm Vault usage: if you will provide VAULT_TOKEN or other secrets, verify the vault manager code (lib/vault/manager.py, src/vault.py) to ensure secrets are not printed, shipped, or sent to external endpoints.
- The registry lists no required env vars but code expects VAULT_* and WP_SITES — ask the author to update metadata and explain exact credentials needed.
- Keep pipeline.require_approval enabled and test the Gate pipeline to ensure HIGH-risk actions require manual approval.
- Review audit logging (logs/audit.jsonl) and retain/forward logs to a secure location you control.
- If you cannot audit the code yourself, avoid granting SSH keys, Vault tokens, or writing to /var/www/html on production. Consider running the tool in read-only mode first and only approve changes after manual review.
If the author can supply an updated manifest declaring required env vars, install steps, and an explanation of approval/audit enforcement, confidence in safety would increase.Like a lobster shell, security has layers — review code before you run it.
latestvk97fa7vf32zr1cj18xy0avd5tx83hvqa
License
MIT-0
Free to use, modify, and redistribute. No attribution required.