AICash Miner
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill is a disclosed AICash miner, but it installs persistent root-level systemd miners, stores an API key in generated code, and lacks important safeguards around setup inputs and resource use.
Review this carefully before installing. Only run it if you intentionally want a continuous crypto-mining service on that machine, trust the AICash endpoint, can tolerate the resource usage, and know how to stop and remove the generated systemd services and stored API key.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
The miner can keep using CPU, network, and API quota in the background until the services are explicitly stopped and disabled.
The setup creates services that automatically start and restart the miner, so the activity can continue after the setup command and across normal system operation.
ExecStart=${NODE} ${INSTALL_DIR}/miner.js
Restart=always
RestartSec=3
...
systemctl enable --now "${SVC_NAME}"Install only on a machine intended for continuous mining, limit the number of instances, and verify how to stop, disable, and remove the generated services before running setup.
A copied or incorrect endpoint, or access to the generated file, could expose or misuse the API key; the service also operates with elevated system-service privileges.
The generated miner stores the supplied AICash API key in a file under a root-oriented install path and sends that key to the configured endpoint, while the registry metadata declares no primary credential.
INSTALL_DIR="/root/.openclaw/workspace/aicash"
...
apiKey: process.env.AICASH_API_KEY || '__API_KEY__'
...
postJSON(CONFIG.endpoint, { 'x-agent-api-key': CONFIG.apiKey },Use a least-privilege or revocable API key, verify the endpoint before setup, prefer environment/secret storage over embedding keys in generated code, and run the service as a dedicated non-root user where possible.
A malformed or malicious endpoint/API key/wallet value from an untrusted source could corrupt the miner script or potentially alter what code is executed by the persistent service.
User-supplied setup values are inserted directly into a generated JavaScript file without escaping or validation before that file is run by systemd.
sed -i "s|__ENDPOINT__|${ENDPOINT}|g; s|__API_KEY__|${API_KEY}|g; s|__WALLET__|${WALLET}|g" "$INSTALL_DIR/miner.js"Generate configuration as JSON or environment variables with proper escaping, and validate endpoint, API key, wallet, service name, and instance count before writing or running code.
A mistaken or excessive instance count can create many persistent services and consume substantial host resources; unusual service names could also make management harder.
The user-controlled service name and instance count drive protected systemd file creation, with no bounds or sanitization shown.
for i in $(seq 1 "$INSTANCES"); do
SVC_NAME="${NAME}"
...
cat > "/etc/systemd/system/${SVC_NAME}.service" << EOFClamp instance counts, sanitize service names, require explicit confirmation before writing /etc/systemd files, and make stop/status scripts handle only services created by this skill.
A user may assume the wallet parameter controls reward delivery, but the provided code does not show it being sent to the mining API.
The script logs the wallet but the shown mining request sends only the block number and API key; this should be reconciled with SKILL.md's statement that --wallet is the EVM wallet address for rewards.
log(`Wallet: ${CONFIG.wallet} | Endpoint: ${CONFIG.endpoint}`);
...
return (await postJSON(CONFIG.endpoint, { 'x-agent-api-key': CONFIG.apiKey }, { block_number: n })).data;Verify with the provider that rewards are bound to the API key or otherwise confirm where the wallet address is used before mining.