Back to skill

Security audit

Binance DCA Test

Security checks for vulnerabilities and agentic risk

Overview

This Binance DCA skill is openly about crypto trading, but it gives high-impact live-trading and scheduled-buy instructions without enough safeguards around confirmation, testnet use, and credential storage.

Review this carefully before installing. Use Binance testnet first, restrict API keys to the minimum permissions needed, disable withdrawals, avoid putting secrets in cron entries, and require explicit confirmation of exchange, pair, amount, order type, and live-vs-testnet status before any buy order is placed.

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 (1)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:66
Finding

Binance API Credentials Embedded in Persistent Cron Configuration

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 66-69
Vulnerability Type: Plaintext sensitive credentials in scheduled-task configuration
Risk Level: Medium

Vulnerable Code

text
# 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 documented cron example instructs users to define Binance API credentials directly in a persistent crontab entry. Although the displayed values are placeholders rather than real credentials, following this pattern would store the actual API key and secret in plaintext within the user's cron configuration.

This contradicts the document's earlier instruction to never store credentials. Cron entries persist across sessions and may be exposed to privileged administrators, backup systems, configuration collection tools, diagnostic output, or any process that gains access to the affected user's crontab. Environment variables also do not provide secret-at-rest protection when their values are written directly into persistent configuration.

The scheduled command initiates an unattended cryptocurrency purchase. Consequently, disclosure of credentials with spot-trading permission could affect real financial assets.

Attack Path

  1. A user follows the documented example and replaces the placeholders with a genuine Binance API key and secret.
  2. The credentials are saved in the user's persistent crontab.
  3. An attacker or compromised administrative, backup, or diagnostic process obtains read access to that cron configuration.
  4. The attacker extracts the API key and secret.
  5. The attacker submits authenticated Binance API requests using the stolen credentials.
  6. Depending on the permissions and restrictions assigned to the key, the attacker queries account information or places unauthorized trades.

This path requires access to the stored cron configuration o ...[truncated 883 chars]

Remediation
View remediation

Remediation Suggestions

  • Do not place API keys or secrets directly in crontab entries.
  • Retrieve credentials at runtime from an operating-system credential store or dedicated secrets manager.
  • If a protected local credentials file is unavoidable, restrict ownership to the service account and permissions to 0600, and load it through a tightly controlled wrapper script without printing its contents.
  • Use a dedicated Binance API key with only the minimum required permissions.
  • Disable withdrawals for any key used by the DCA process.
  • Apply Binance-supported source-IP allowlisting and rotate keys after suspected disclosure.
  • Run and validate the workflow against Binance testnet before enabling real transactions.
  • Add per-order and cumulative spending limits, duplicate-order protection, explicit response-status verification, and alerting for every executed or rejected order.
  • Replace the insecure documentation example with a secret-manager-based invocation and clearly document credential rotation and revocation procedures.
Vulnerability Patterns
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Missing User Warnings

High
Category
Not specified by scanner
Confidence
97% confidence
Finding

The skill documents commands that place live market and limit buy orders but does not prominently warn that these are real-fund, potentially irreversible trades on a live exchange by default. In the context of cryptocurrency trading, users may mistake examples for simulations, and a single unintended invocation can immediately commit funds at market conditions.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
94% confidence
Finding

The trigger description is broad enough to activate on generic investing, accumulation, or spot-purchase requests, which can cause the agent to invoke a live-trading skill in situations where the user may have only wanted education or analysis. In a financial skill with order-execution capability, overbroad invocation increases the chance of unintended tool use and can lead to real-money actions being suggested or initiated in the wrong context.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.