T09 · Insecure Skill Coding Practices
- Location
scripts/auto-sync.sh:10- Finding
Automatic Git synchronization can upload API keys, private keys, and request data
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill mostly matches its human-help purpose, but it needs review because it can keep running in the background, use a local OpenClaw token, and accidentally publish local secrets through Git auto-sync.
Review before installing. Use only with a trusted HeySummon endpoint, prefer HTTPS for any non-local server, avoid sending secrets or sensitive conversation context, do not run auto-sync.sh until a restrictive .gitignore and staging allowlist are added, and treat .env, providers.json, .keys, .requests, watcher logs, and the OpenClaw gateway token as sensitive credentials.
scripts/auto-sync.sh:10Automatic Git synchronization can upload API keys, private keys, and request data
scripts/submit-request.sh:101Questions and conversation context are transmitted without the claimed end-to-end encryption
scripts/add-provider.sh:12API credentials can be sent to arbitrary or unencrypted endpoints
scripts/platform-watcher.sh:23Persistent watcher reads a high-value OpenClaw gateway token and invokes privileged local APIs
scripts/crypto.mjs:23Cryptographic private keys are created without explicit restrictive permissions
scripts/submit-request.sh:31Predictable shared temporary file permits symlink and race-condition attacks
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
.env file:
cp .env.example .env
# Edit .env with your API key and platform URL
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Create .env file:
cp .env.example .env
# Edit .env with your API key and platform URL
Register your first provider:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Create .env file:
cp .env.example .env
# Edit .env with your API key and platform URL
Register your first provider:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Create .env file:
cp .env.example .env
# Edit .env with your API key and platform URL
Register your first provider:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Create .env file:
cp .env.example .env
# Edit .env with your API key and platform URL
Register your first provider:
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
fi
# Fetch provider info
RESPONSE=$(curl -s "${BASE_URL}/api/v1/whoami" -H "x-api-key: ${API_KEY}")
ERROR=$(echo "$RESPONSE" | node -e "let d='';process.stdin.on('data',c=>d+=c);process.stdin.on('end',()=>{try{const j=JSON.parse(d);if(j.error)console.log(j.error)}catch(e){}})" 2>/dev/null)
if [ -n "$ERROR" ]; then
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# List registered providers
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
SKILL_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
[ -f "$SKILL_DIR/.env" ] && set -a && source "$SKILL_DIR/.env" && set +a
PROVIDERS_FILE="${HEYSUMMON_PROVIDERS_FILE:-$SKILL_DIR/providers.json}"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# List registered providers
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
SKILL_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
[ -f "$SKILL_DIR/.env" ] && set -a && source "$SKILL_DIR/.env" && set +a
PROVIDERS_FILE="${HEYSUMMON_PROVIDERS_FILE:-$SKILL_DIR/providers.json}"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# List registered providers
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
SKILL_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
[ -f "$SKILL_DIR/.env" ] && set -a && source "$SKILL_DIR/.env" && set +a
PROVIDERS_FILE="${HEYSUMMON_PROVIDERS_FILE:-$SKILL_DIR/providers.json}"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# List registered providers
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
SKILL_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
[ -f "$SKILL_DIR/.env" ] && set -a && source "$SKILL_DIR/.env" && set +a
PROVIDERS_FILE="${HEYSUMMON_PROVIDERS_FILE:-$SKILL_DIR/providers.json}"
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
mkdir -p "$(dirname "$EVENTS_FILE")"
local TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
echo "{\"timestamp\":\"$TIMESTAMP\",\"message\":$(node -e "console.log(JSON.stringify(process.argv[1]))" "$MSG" 2>/dev/null)}" >> "$EVENTS_FILE"
curl -s -X POST "http://127.0.0.1:${OPENCLAW_PORT}/cron/wake" \
-H "Authorization: Bearer ${OPENCLAW_TOKEN}" \
-H "Content-Type: application/json" \
-d "{\"text\":\"$MSG\",\"mode\":\"now\",\"agentId\":\"secondary\"}" \
The script uses EVENT_REQ_ID derived from untrusted event JSON to build a filesystem path and passes it directly to rm -f. An attacker able to influence requestId could use path traversal values like ../../somefile to delete arbitrary files accessible to the current user, especially because no basename or character validation is enforced.
# Remove closed/expired requests
EVENT_TYPE=$(echo "$data" | node -e "let d='';process.stdin.on('data',c=>d+=c);process.stdin.on('end',()=>{try{console.log(JSON.parse(d).type)}catch(e){}})" 2>/dev/null)
if [ "$EVENT_TYPE" = "closed" ] && [ -n "$EVENT_REQ_ID" ]; then
rm -f "$REQUESTS_DIR/$EVENT_REQ_ID"
fi
fi
done < "$FIFO"
The script uses a fixed path in /tmp for intermediate provider data, then reads and deletes it. Because /tmp is shared, another local user or process could pre-create or race this file, causing data spoofing, symlink attacks, or unintended file deletion depending on execution context.
}
" "$PROVIDERS_FILE" "$PROVIDER_NAME" 2>"/tmp/.heysummon-provider-match")
RESOLVED_PROVIDER=$(cat /tmp/.heysummon-provider-match 2>/dev/null)
rm -f /tmp/.heysummon-provider-match
fi
# Fallback: if no provider specified or not found, use default from env
The README encourages submitting conversation context and routing notifications through external services, including a human-provider workflow, without a prominent privacy warning about sharing potentially sensitive prompts, messages, or identifiers outside the local agent environment. In a HITL skill, that omission increases the chance users will send secrets, regulated data, or internal context to third parties unintentionally.
The README makes a security claim that API keys are never passed as CLI arguments, but it also documents add-provider.sh "hs_cli_..." usage that places a live secret directly in the shell command line. Command-line arguments are commonly exposed through shell history, process listings, audit logs, and terminal recordings, so this inconsistency can cause credential disclosure.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
chmod 600 .env
chmod 700 .keys/
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
chmod 600 .env
chmod 700 .keys/
The script persists the supplied client API key directly into providers.json in plaintext, with no warning, permission hardening, or indication that this creates a local credential store. If that file is later read by other users, checked into source control, or exposed by backups/logging, the key can be reused to impersonate the client and access provider-linked functionality.
The script comment claims it syncs only the heysummon skill, but git add -A stages all changes in the repository and the later commit/push publishes them. This mismatch is dangerous because operators may trust the narrower description and unintentionally upload unrelated files, secrets, or work-in-progress content.
The script automatically commits and pushes to origin main without any user warning, approval, or review step once changes are detected. In a skill context, this increases the chance of silently publishing unintended modifications or sensitive data, especially if run on a schedule as the comments suggest.
The script writes private signing and encryption keys directly to disk using default filesystem permissions and without restricting access or warning the operator about secure storage. On multi-user systems or in permissive umask environments, this can expose long-term private keys to other local users or accidental inclusion in backups, logs, or repositories, compromising all encrypted communications and signatures.
The script intentionally prints the first 12 characters of each stored provider API key to stdout. Even partial credential disclosure is sensitive because prefixes can aid key identification, correlation across systems, leakage into logs or screenshots, and reduce secrecy if other portions are exposed elsewhere.
The header presents the script as a passive SSE listener, but the implementation also fetches full message bodies and forwards notifications through a local tool gateway. That mismatch reduces informed consent and can cause operators to run a component with broader data access and transmission behavior than advertised.
The script reads an unrelated OpenClaw gateway bearer token from the user's home directory and uses it to invoke a separate local tooling API, expanding the trust boundary beyond the stated SSE-watcher role. This creates a covert bridge between HeySummon event data and another privileged local service, so compromise or misuse of event content can trigger actions or expose data through an unrelated channel without explicit consent.
Reading a local gateway token from the user's OpenClaw config without a user-facing warning silently accesses sensitive credentials belonging to another system. Even if intended for convenience, this violates least surprise and can enable unauthorized use of a privileged local API under the user's identity.
Detected: suspicious.exposed_secret_literal