T09 · Insecure Skill Coding Practices
- Location
scripts/monitor.sh:6- Finding
Hard-Coded NOFX API Credential Exposed in Source Code and Request URLs
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is broadly aligned with automated crypto reporting, but it includes scheduled shell automation, unsafe credential handling, and concrete script weaknesses that require review before use.
Install only if you are comfortable with recurring background jobs that call external market APIs and send messages to Telegram. Before use, remove and rotate the embedded NOFX key, require secrets from protected configuration, avoid putting keys in prompts or URLs where possible, fix the monitor.sh path interpolation bug, add an easy cron disable path, and avoid the optional video/TTS pipeline unless its third-party data sharing and dependencies are explicitly approved.
scripts/monitor.sh:6Hard-Coded NOFX API Credential Exposed in Source Code and Request URLs
scripts/monitor.sh:7Arbitrary Python Code Injection Through NOFX_KNOWN_FILE
SKILL.md:63Documentation Recommends Disabling TLS Certificate Verification
references/video-pipeline.md:12Unpinned Third-Party Package Retrieval and Execution Through npx
The documented behavior presents the skill as a broad market-report generator, but the referenced behavior includes monitoring, change detection, cron automation, and local state persistence not clearly disclosed in the description. That mismatch is security-relevant because users may authorize the skill expecting passive reporting while it actually performs ongoing automated actions and stores data locally.
The skill asks for an API auth key and says NOFX endpoints use ?auth=KEY query parameters, while also suggesting passing the key via environment variables, without warning about exposure in logs, process listings, shell history, cron definitions, proxies, or server access logs. Query-string credentials are especially sensitive because they are commonly recorded by intermediaries and observability systems, making credential leakage likely if the setup is used as written.
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
BASE="${NOFX_BASE:-https://nofxos.ai}"
KNOWN_FILE="${NOFX_KNOWN_FILE:-$HOME/.openclaw/workspace/nofx-ai500-known.json}"
RESPONSE=$(curl -s "${BASE}/api/ai500/list?auth=${KEY}")
CURRENT=$(echo "$RESPONSE" | python3 -c "
import sys, json
The skill directs the agent to create cron jobs and run scripts/monitor.sh via exec, which implies shell execution and likely local state/file writes, yet it declares no permissions or allowed-tools scope. This under-specification is dangerous because consumers and enforcement layers cannot accurately constrain what the skill is allowed to do, increasing the chance of unintended command execution or filesystem modification.
The activation text is broad enough to match common requests for crypto updates, alerts, or summaries, which can cause the skill to trigger in situations where the user did not intend to enable recurring monitoring or message delivery. In this context, over-broad invocation is risky because the skill requests credentials and sets up automated external communications.
The skill instructs users to set up repeated polling of external APIs and automated delivery to Telegram or other messaging targets, but it does not clearly warn that this creates ongoing outbound transmissions and repeatedly shares destination identifiers. In a crypto-reporting context, this increases the risk of unintended data egress, misdelivery to the wrong channel, and silent background activity continuing after initial setup.
The file contains a hardcoded API key and automatically sends it to the NOFX service on every request. Embedding credentials in source code makes them recoverable by anyone with code access and enables unauthorized reuse of the key, quota abuse, and potential access to associated account data or billing.
The skill silently transmits an embedded authentication token in outbound requests without clear user awareness. This combines secret exposure with undisclosed credential use, increasing the chance of misuse, accidental redistribution, and trust violations for anyone deploying the skill.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
def curl_json(url):
try:
r = subprocess.run(["curl", "-s", "-f", url], capture_output=True, text=True, timeout=15)
if r.returncode != 0:
return None
return json.loads(r.stdout)
The template directs the agent to execute a shell script (bash <skill-dir>/scripts/monitor.sh) as part of an automated cron-driven workflow. That expands the skill from report generation into arbitrary local command execution, which is risky because the script path, script contents, or surrounding environment could be modified to run unintended commands without further user review.
The template embeds API connection details and a key placeholder directly inside the agent message payload (API Base: <BASE> Key: <KEY> Auth: ?auth=KEY). Placing secrets in prompt text increases the chance of accidental exposure through logs, transcripts, debugging output, or downstream tool use, especially in an automated scheduled job.
The markdown instructs command execution but provides no explicit warning that enabling this monitor causes the agent to run a local shell script on a schedule. In an automation context, lack of disclosure increases the risk that operators enable a capability with system-side effects they did not fully understand.
The template includes handling of sensitive API credentials but does not warn users about secure storage, exposure risks, or the insecurity of placing keys in prompts and URL query parameters. This omission can lead to unsafe operational practices and secret leakage in logs or message history.
The cron payload explicitly instructs the agent to send the generated market report to Telegram via a message tool, but it provides no user-facing warning, approval step, or data-classification guard before external transmission. In an automated reporting skill, this creates a real risk of unintended disclosure of report contents, API-derived intelligence, or future inclusion of sensitive configuration/runtime data to a third-party messaging platform.
Using npx remotion render without pinning an exact package version makes the build depend on whatever version npx resolves at runtime. That creates a supply-chain risk: a malicious or compromised upstream release could execute unexpected code during report generation, especially because npm packages commonly run install-time or CLI code locally.
The documented TTS integration sends report narration content to a third-party provider, which expands the skill from local report generation into external content transmission. Even if intended for voice narration, this broadens the data exposure surface and introduces dependency on an outside service not clearly scoped in the skill description.
The TTS example transmits narration_text to api.minimax.chat with no privacy notice, consent flow, or guidance on what data is safe to include. If generated reports ever contain proprietary trading notes, internal commentary, or user-specific content, this could leak sensitive information to a third party without user awareness.
The endpoint https://api.minimax.chat/v1/t2a_v2 is an explicit external transmission path for generated narration content. In a market-intelligence skill, outbound transfer of generated text can expose proprietary analysis or operational details, making this more sensitive than generic public-content processing.
"voice_setting": {"voice_id": "cute_girl", "speed": 1.0, "vol": 1.0, "pitch": 0}, "audio_setting": {"sample_rate": 32000, "bitrate": 128000, "format": "mp3"} }
The manifest describes producing AI500 market reports and Telegram/message summaries, but this file adds a separate media-processing workflow requiring local command-line execution via ffmpeg. Shell-driven video rendering/assembly is not an obvious or declared requirement for a report-generation skill focused on crypto signal monitoring.
The script embeds a default API credential directly in source via NOFX_KEY:-cm_568c67eae410d912c54c, which exposes the credential to anyone who can read the skill or repository. Hardcoded secrets are commonly reused, copied into logs, or accidentally committed, enabling unauthorized API use and making secret rotation difficult.
The script sends the API credential as a URL query parameter in a curl request, which can leak through shell history, process listings, proxy logs, web server logs, and monitoring systems even when HTTPS is used. In this case the risk is elevated because the credential may also be the hardcoded default secret from line 6.
The script makes multiple HTTP requests to external services using subprocess-invoked curl, including to NOFX and Binance endpoints. Although the module docstring says it fetches real data via curl, there is no runtime notice, confirmation, or more specific disclosure about contacting third-party services and transmitting requested symbols and auth parameters.
The natural-language guidance hard-codes a specific voice setting for narration rather than presenting it as a selectable option. This can constitute a language/locale-style policy issue when user-facing presentation attributes are forced without opt-in or alternative choices.
The script updates the local state file by opening KNOWN_FILE for writing, which modifies user data on disk. Aside from an inline comment, there is no user-facing notice, confirmation, or descriptive warning that running the script will create or overwrite the known-coins file.
In the removed-coins path, the script rewrites KNOWN_FILE with the current remote list, which is a file write affecting persistent local state. The script does not provide a user-facing warning or clear disclosure that this overwrite will occur.
No suspicious patterns detected.