Back to skill

Security audit

Crypto Auto Trader Strategy

Security checks for vulnerabilities and agentic risk

Overview

This skill is for automated crypto trading and is transparent about that, but it asks users to add exchange API keys and run a persistent bot without enough safety guidance.

Only install or use this after confirming it supports paper trading or testnet first. Use exchange API keys with withdrawals disabled, narrow trading permissions, and IP allowlisting where available, and avoid storing production secrets in a repository config file. Review and pin dependencies before running it with real funds.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:50
Finding
Unpinned Third-Party Runtime Dependencies## Vulnerability Details **File Location**: `SKILL.md`, line 50 **Vulnerability Type**: Unpinned third-party dependencies **Risk Level**: Medium **Code Snippet**: ```bash npm install ccxt https-proxy-agent ``` ### Technical Analysis The installation command does not specify dependency versions, a lockfile, integrity hashes, or an expected package registry. It therefore resolves mutable package versions from the user's configured npm registry at installation time. npm installation may also execute package lifecycle scripts. Because the advertised application handles cryptocurrency exchange credentials and trading operations, compromise of a direct or transitive dependency could affect highly sensitive assets. The repository contains no lockfile or other dependency-integrity control that would make installation reproducible or constrain users to reviewed versions. ### Attack Path 1. An attacker compromises a named package, one of its transitive dependencies, or the registry through which it is resolved. 2. The attacker publishes a malicious version or injects malicious lifecycle behavior. 3. A user follows the documented unpinned `npm install` command. 4. npm resolves the malicious release and may execute its lifecycle scripts during installation. 5. The malicious dependency executes in the user's environment and could access files, process environment values, application configuration, or runtime trading data available to that process. ### Impact Assessment Exploitation could permit arbitrary code execution with the privileges of the user running npm or the trading application. Within that scope, an attacker could potentially obtain exchange API credentials, modify trading logic, place unauthorized orders when usable credentials are available, or access other files readable by the process. The exact impact cannot be verified further because the advertised application source code is absent from the audited project.
Remediation
## Remediation Suggestions - Pin every direct dependency to a reviewed exact version. - Generate, review, and commit a package lockfile. - In deployment documentation, replace mutable installation instructions with `npm ci`, which installs from the lockfile. - Use the expected official registry explicitly and protect CI or local npm configuration from registry substitution. - Review direct and transitive dependencies, including lifecycle scripts, before release. - Use automated vulnerability monitoring and update dependencies through a controlled review process. - Consider disabling lifecycle scripts where compatible with the application and verify package integrity during CI and deployment.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:51
Finding
Plaintext Exchange API Credential Storage Guidance## Vulnerability Details **File Location**: `SKILL.md`, line 51 **Vulnerability Type**: Plaintext sensitive credential storage **Risk Level**: High **Code Snippet**: ```bash # 編輯 config.json 填入API Key ``` The comment instructs the user to edit `config.json` and place an API key in it. ### Technical Analysis The deployment instructions direct users to store cryptocurrency exchange API credentials in a plaintext JSON configuration file. The audited project provides no `.gitignore`, restrictive file-permission instructions, secret-manager integration, encryption controls, credential-scope requirements, or rotation procedure. A plaintext configuration file can be exposed through accidental source-control commits, filesystem backups, support bundles, synchronization services, permissive file access, or unrelated processes operating under the same account. Although the document does not explicitly request withdrawal-enabled credentials, it also does not require least-privilege, trade-only, or IP-restricted API keys. ### Attack Path 1. A user follows the instructions and stores an exchange API key in `config.json`. 2. The file is accidentally committed, copied to a shared location, included in a backup or diagnostic archive, synchronized externally, or read by another local process or user. 3. An attacker extracts the API key and any corresponding secret from the exposed configuration. 4. The attacker authenticates to the exchange API. 5. The attacker performs actions permitted by the key, potentially including account inspection, unauthorized orders, or withdrawals if the user granted withdrawal privileges. ### Impact Assessment The attacker obtains the permissions assigned to the compromised exchange API credentials. A trade-enabled key could allow unauthorized purchases, sales, leveraged positions, or deliberate loss-inducing trades. A withdrawal-enabled key could expose account funds directly. Read access could disclos ...[truncated 153 chars]
Remediation
## Remediation Suggestions - Do not store production exchange credentials directly in `config.json`. - Load secrets through an operating-system, container, CI/CD, or cloud secret manager and inject them only at runtime. - If a local secret file is unavoidable, keep it outside the repository, add its path to `.gitignore`, apply restrictive owner-only permissions, and provide a non-secret example configuration separately. - Require least-privilege, trade-only API keys with withdrawals disabled. - Enforce exchange-side IP allowlisting wherever supported. - Use separate credentials for development, testing, and production. - Document credential rotation, immediate revocation, and exposure-response procedures. - Prevent secrets from entering logs, error reports, backups, support bundles, and process listings. - Add automated secret scanning to source-control and release workflows.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The skill explicitly instructs users to place exchange API keys into a config file and start an automated trading bot, but it does not prominently warn that these credentials can enable live trading and potentially account-draining actions if misconfigured, over-permissioned, or exposed. In the context of crypto auto-trading, this omission materially increases user risk because users may supply production keys without understanding least-privilege requirements, testnet separation, or the consequences of immediate live execution.

Static analysis

No suspicious patterns detected.