Back to skill

Security audit

Binance Dca Tool

Security checks for vulnerabilities and agentic risk

Overview

This skill is a coherent Binance DCA trading tool, but it needs Review because it can place real-money trades and has unsafe credential, endpoint, and argument-handling patterns.

Install only if you are comfortable giving an agent-assisted shell script access to Binance API credentials and potential live spot-buy authority. Use testnet first, restrict API keys to the minimum permissions with withdrawals disabled and IP allowlisting, avoid inline cron secrets, and do not run live buys or recurring schedules without explicit confirmation and spending limits.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/dca.sh:165
Finding
Arbitrary Python Code Execution Through Unvalidated DCA Plan Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/dca.sh`, lines 165-195 **Vulnerability Type**: Python source-code injection **Risk Level**: High ### Vulnerable Code ```bash python3 -c " amount = float('${amount}') periods = int('${periods}') freq = int('${frequency}') price = float('${price}') total_invested = amount * periods btc_at_current = total_invested / price total_days = freq * periods print(f'Total invest: \${total_invested:,.2f}') print(f'At cur. price: {btc_at_current:.8f} ${symbol%%USDT*}') print(f'Time span: {total_days} days (~{total_days/30:.1f} months)') print() print('Scenario Analysis (if avg price over period is):') for pct in [-30, -20, -10, 0, 10, 20, 50, 100]: avg = price * (1 + pct/100) coins = total_invested / avg value = coins * price * (1 + pct/100) pnl = value - total_invested pnl_pct = (pnl / total_invested) * 100 sign = '+' if pnl >= 0 else '' print(f' {pct:+4d}% -> avg \${avg:>10,.2f} -> {coins:.8f} BTC -> PnL: {sign}\${pnl:>10,.2f} ({sign}{pnl_pct:.1f}%)') " 2>/dev/null || die "Python3 required for plan calculations" ``` ### Technical Analysis The `amount`, `periods`, and `frequency` command-line arguments are interpolated directly into source code passed to `python3 -c`. The `plan` action does not validate these arguments before interpolation. Because each value is placed inside a single-quoted Python string literal, an attacker can supply a value containing a quote, terminate that literal, and append arbitrary Python statements. The shell constructs the resulting Python program before invoking the interpreter. For example, an argument shaped like the following demonstrates the injection primitive: ```text 1'); __import__('os').system('id'); # ``` This changes the generated statement into executable Python containing an attacker-controlled call to `os.system`. The vulnerability is not limited to shell commands; injected Python can directly read files, open network connec ...[truncated 1173 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Validate `amount`, `frequency`, and `periods` before invoking Python. Enforce positive decimal or integer formats and reasonable upper bounds. - Never construct executable Python source by interpolating command-line arguments. - Pass values as positional arguments instead: ```bash python3 - "$amount" "$periods" "$frequency" "$price" "$symbol" <<'PY' import sys amount = float(sys.argv[1]) periods = int(sys.argv[2]) freq = int(sys.argv[3]) price = float(sys.argv[4]) symbol = sys.argv[5] # Perform calculations here. PY ``` - Reject non-finite values, zero or negative amounts, zero or negative frequencies, and excessive period counts. - Treat API-derived values such as `price` as untrusted input and parse them as JSON before conversion. - Add regression tests containing quotes, semicolons, newlines, Python expressions, and shell metacharacters to confirm that they are rejected or handled only as data. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
scripts/dca.sh:16
Finding
Unrestricted API Base URL Exposes Binance API Keys and Enables Server-Side Request Forgery<![CDATA[ ## Vulnerability Details **File Location**: `scripts/dca.sh`, lines 16-57 **Vulnerability Type**: Untrusted endpoint configuration, credential disclosure, and SSRF **Risk Level**: High ### Vulnerable Code ```bash BASE_URL="${BINANCE_BASE_URL:-https://api.binance.com}" RECV_WINDOW="${BINANCE_RECV_WINDOW:-5000}" ``` ```bash api_public() { local endpoint="$1" query="${2:-}" curl -sf "${BASE_URL}${endpoint}?${query}" 2>/dev/null || die "API request failed: ${endpoint}" } api_signed() { local method="$1" endpoint="$2" query="${3:-}" check_keys local ts ts=$(timestamp) query="${query:+${query}&}recvWindow=${RECV_WINDOW}&timestamp=${ts}" local sig sig=$(sign "$query") query="${query}&signature=${sig}" if [[ "$method" == "GET" ]]; then curl -sf -H "X-MBX-APIKEY: ${BINANCE_API_KEY}" \ "${BASE_URL}${endpoint}?${query}" 2>/dev/null || die "Signed API request failed: ${endpoint}" else curl -sf -X "$method" -H "X-MBX-APIKEY: ${BINANCE_API_KEY}" \ -d "$query" "${BASE_URL}${endpoint}" 2>/dev/null || die "Signed API request failed: ${endpoint}" fi } ``` ### Technical Analysis `BINANCE_BASE_URL` is accepted without validation and is used as the destination for both public and authenticated HTTP requests. The script does not enforce HTTPS, validate the hostname, restrict ports, or allow only documented Binance production and testnet origins. Authenticated requests include the Binance API key in the `X-MBX-APIKEY` header. They also disclose signed query data, timestamps, account-query parameters, and order parameters to the configured destination. Although the Binance secret key itself is not transmitted, an attacker-controlled server can capture the API key and signed request material. The same endpoint control can be used to make requests to loopback addresses, private network services, or cloud metadata endpoints. The request paths are determined by the script, which limits flexibility, but the destination host an ...[truncated 1402 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Enforce an exact allowlist of supported origins, for example: - `https://api.binance.com` - `https://testnet.binance.vision` - Reject every non-HTTPS scheme, unexpected hostname, user-information component, query string, fragment, and non-approved port. - Normalize and compare the complete origin rather than relying on substring or suffix matching. - Prefer a mode variable such as `BINANCE_ENV=production|testnet` and map it internally to hardcoded trusted URLs. - Use curl options that constrain protocols, such as: ```bash curl --proto '=https' --proto-redir '=https' ... ``` - Apply egress controls where possible so the process cannot contact loopback, link-local, metadata, or private-network destinations unless explicitly required. - Use Binance API keys restricted to trading-only operations, disable withdrawals, apply IP allowlisting, and rotate any API key that may have been sent to an untrusted endpoint. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:65
Finding
Scheduling Guidance Encourages Persistent Plaintext Storage of Exchange Credentials<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 65-70 **Vulnerability Type**: Plaintext sensitive credential storage **Risk Level**: High ### Vulnerable Code ```markdown For automated recurring buys, suggest setting up a cron job or OpenClaw cron: ``` # Example: buy $50 BTC every Monday at 9am UTC 0 9 * * 1 BINANCE_API_KEY=... BINANCE_SECRET_KEY=... /path/to/dca.sh buy BTCUSDT 50 ``` ``` ### Technical Analysis The scheduling example directs users to place the Binance API key and secret key directly into a crontab entry. In practical use, the placeholder values would be replaced with real credentials and stored persistently as plaintext. This contradicts the document's separate instruction to never store credentials. Crontab contents may be exposed through administrative access, backups, support bundles, configuration-management systems, shell history used to install the entry, or process-environment inspection by sufficiently privileged local users. Because the scheduled command performs automated exchange purchases, compromise of the stored credentials could have direct financial consequences. ### Attack Path 1. A user follows the documented cron example and substitutes real Binance credentials. 2. The resulting crontab persistently stores both credentials in plaintext. 3. An attacker obtains access to the user's crontab, a backup, command history, diagnostic output, or a process environment created by cron. 4. The attacker extracts the API key and secret key. 5. The attacker uses the credentials within the permissions assigned to the Binance API key, potentially including account queries and unauthorized trading. ### Impact Assessment Exposure provides the attacker with the full API credential pair. The resulting scope depends on the permissions and restrictions configured for that key. For a trading-enabled key, an attacker may be able to inspect balances and trade history or place unauthorized orders. If broader permission ...[truncated 198 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove inline credentials from the cron example. - Load credentials at runtime from a dedicated secret manager or another protected credential provider. - If a local environment file is unavoidable, store it outside the project directory, make it owned by the executing user, and set permissions to `0600`. - Use a wrapper script that retrieves credentials securely immediately before execution rather than embedding them in the crontab. - Ensure secrets are excluded from source control, backups, logs, diagnostics, and shell history. - Create a dedicated Binance API key with: - Only the minimum account-reading and spot-trading permissions required. - Withdrawals disabled. - An IP-address allowlist. - Regular rotation and monitoring. - Add confirmation controls, transaction-size limits, and alerting for automated purchases. - Update the documentation with a safe example that references a protected credential-loading mechanism without displaying or persisting secret values inline. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (4)

Missing User Warnings

High
Confidence
97% confidence
Finding
The skill documents live market buys and automated scheduled trading without a prominent warning that these actions can immediately spend funds, incur fees, and create irreversible market exposure. Because the skill also suggests cron-based automation, the absence of strong risk and confirmation language materially increases the chance of accidental or repeated real-money trades.

Lp3

Medium
Category
MCP Least Privilege
Confidence
95% confidence
Finding
The skill exposes shell-based operational capability but does not declare any tool scope or allowed-tools restrictions. In an agent environment, this can enable unintended command execution paths or broader-than-expected access, especially when the skill includes commands that can place live trades and handle API credentials.

Vague Triggers

Medium
Confidence
88% confidence
Finding
The trigger phrases are broad enough to match general financial-planning or accumulation discussions, which increases the chance that the agent invokes a live-trading skill when the user only wanted advice or analysis. In this context, overbroad routing is risky because the skill is capable of executing crypto purchases, not merely simulating them.

External Transmission

Medium
Category
Data Exfiltration
Content
curl -sf -H "X-MBX-APIKEY: ${BINANCE_API_KEY}" \
      "${BASE_URL}${endpoint}?${query}" 2>/dev/null || die "Signed API request failed: ${endpoint}"
  else
    curl -sf -X "$method" -H "X-MBX-APIKEY: ${BINANCE_API_KEY}" \
      -d "$query" "${BASE_URL}${endpoint}" 2>/dev/null || die "Signed API request failed: ${endpoint}"
  fi
}
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.