Back to skill

Security audit

OKX API

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent OKX trading helper, but it exposes exchange credentials broadly and includes an unrelated pre-approved git push permission.

Review before installing. Use demo mode or separate least-privilege OKX API keys, prefer read-only keys for account queries, avoid global credential injection for live trading keys, remove the packaged .claude git-push allow rule, and require explicit confirmation before any live order placement, amendment, or cancellation.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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
Findings (3)

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
.claude/settings.local.json:2
Finding

Unrelated Git Push Permission Violates Least Privilege

Content
View full analysis

Vulnerability Details

File Location: .claude/settings.local.json, lines 2-5
Vulnerability Type: Pre-authorized repository write operation
Risk Level: Medium

json
"permissions": {
  "allow": [
    "Bash(git push origin main)"
  ]
}

Technical Analysis

The local Agent configuration explicitly allows git push origin main without requiring an additional authorization prompt. Pushing source code is unrelated to the Skill's declared OKX market-data, account-management, WebSocket, and trading functionality.

This permission breaks least-privilege boundaries by granting a consequential source-control capability that is unnecessary for any documented Skill operation. Although the rule only authorizes the specified command and does not itself create commits, it can publish existing or newly created local commits if the execution environment has valid Git credentials and write access to the remote repository.

Attack Path

  1. A user opens or runs an Agent session with this project configuration active.
  2. The runtime imports the allow rule from .claude/settings.local.json.
  3. Existing local commits are present, or another authorized action modifies and commits repository content.
  4. A malicious instruction, compromised dependency, prompt injection, or mistaken Agent action invokes git push origin main.
  5. The configured allow rule suppresses the normal approval boundary for that command.
  6. Git uses the user's configured credentials to publish commits to the remote main branch.

Exploitation therefore depends on the environment having push-capable credentials and commits that are not already present on the remote.

Impact Assessment

The permission can expose the repository-write privileges of the current Git identity. Potential impact includes:

  • Unauthorized publication of local source changes or sensitive committed files.
  • Modification of the remote default branch when bran ...[truncated 303 chars]
Remediation
View remediation

Remediation Suggestions

  1. Remove .claude/settings.local.json from the distributed Skill package.
  2. Delete the Bash(git push origin main) allow rule.
  3. Require explicit, per-operation user confirmation for every Git push.
  4. Protect the remote default branch with mandatory pull requests, reviews, and status checks.
  5. Use Git credentials scoped to the minimum necessary repositories and operations.
  6. Add repository checks that reject packaged local Agent permission files unless they are required and documented.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:25
Finding

OKX Credentials Are Configured for Injection into Every Agent Session

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 25-45
Vulnerability Type: Excessively broad secret exposure through global environment configuration
Risk Level: High

markdown
Store credentials in `~/.openclaw/openclaw.json` under the top-level `env` field. OpenClaw automatically injects these into the agent environment:

```json
{
  "env": {
    "OKX_API_KEY": "your-api-key",
    "OKX_SECRET_KEY": "your-secret-key",
    "OKX_PASSPHRASE": "your-passphrase",
    "OKX_DEMO": "1"
  }
}

Set OKX_DEMO=1 to use sandbox mode (paper trading). Remove or set to 0 for live trading.

You can also export these in your shell:

bash
export OKX_API_KEY="your-api-key"
export OKX_SECRET_KEY="your-secret-key"

The same global configuration practice is repeated in README.md and README.zh.md.

Technical Analysis

The documentation directs users to place API credentials in a top-level environment configuration that is automatically injected into Agent sessions. Environment variables are process-level data and are commonly inherited by child processes. Consequently, unrelated Skills, scripts, dependencies, shell commands, or compromised tools running in the same Agent environment may be able to read the OKX API key, secret key, and passphrase.

Authentication legitimately requires these values, but exposing them to every Agent session is broader than necessary. The secrets should only be available to the narrowly scoped process that creates authenticated OKX requests.

The practical severity depends on permissions assigned to the user's OKX API key. A read-only key limits impact to account-data disclosure, while a trading-enabled key may permit live order placement, amendment, and cancellation. The project does not perform withdrawals, but the supplied helper does not enforce API-key permissions server-side.

Attack Path

  1. A user follows the configuration instructions and stor ...[truncated 1253 chars]
Remediation
View remediation

Remediation Suggestions

  1. Replace global session environment injection with a scoped secret-management mechanism.
  2. Inject credentials only into the dedicated OKX request process and remove them immediately after use.
  3. Do not expose live trading credentials to unrelated Skills or general-purpose shell sessions.
  4. Recommend separate API keys for read-only, demo, and live trading operations.
  5. Explicitly instruct users to disable withdrawal permission and grant only the minimum necessary OKX permissions.
  6. Require an OKX IP allowlist wherever operationally possible.
  7. Protect credential configuration files with restrictive filesystem permissions and exclude them from version control, logs, and diagnostic output.
  8. Add a fail-closed live-trading mode that requires an explicit live-mode setting rather than treating an absent OKX_DEMO value as live.
  9. Rotate any credential that may have been exposed to an untrusted Agent session.

T08 · Insecure Dependencies

Note
Location
README.md:164
Finding

Third-Party Python Dependencies Are Installed Without Version or Integrity Pinning

Content
View full analysis

Vulnerability Details

File Location: README.md, lines 164-174
Vulnerability Type: Unpinned third-party dependency installation
Risk Level: Low

markdown
## Requirements

requests websocket-client # only for websocket-ticker.py

text

Install:

```bash
pip install requests websocket-client

The WebSocket example also repeats the unpinned installation instruction:

python
Usage:
    pip install websocket-client
    python websocket-ticker.py BTC-USDT ETH-USDT

Technical Analysis

The installation command resolves the latest versions of requests and websocket-client available from the user's configured Python package index. The project supplies neither exact version constraints nor cryptographic hashes or a lock file.

This makes installation non-reproducible and permits dependency contents to change after the Skill has been reviewed. If a future package release, package-index account, configured mirror, or dependency chain is compromised, malicious code could execute during installation or when imported by the credential-bearing examples.

The audited package names are established packages, and no evidence was found that the currently referenced dependencies are malicious. This finding concerns the absence of supply-chain controls rather than a confirmed malicious dependency.

Attack Path

  1. A user runs pip install requests websocket-client.
  2. Pip resolves mutable package versions from the configured package index or mirror.
  3. A compromised release, mirror, maintainer account, or transitive dependency supplies malicious code.
  4. The malicious package executes during installation or when imported.
  5. The package runs in the context of the user and may access OKX environment variables when the examples are executed.
  6. It can alter requests, capture credentials, manipulate trading operations, or access other resources available to the Python process.

...[truncated 590 chars]

Remediation
View remediation

Remediation Suggestions

  1. Add a lock file or requirements file containing exact, reviewed package versions.
  2. Generate and verify package hashes, for example with pip hash-checking mode.
  3. Install dependencies in an isolated virtual environment.
  4. Explicitly use a trusted package index and prevent unintended fallback to untrusted mirrors.
  5. Enable automated dependency vulnerability and provenance monitoring.
  6. Review and update pinned versions through a controlled process.
  7. Separate dependency installation from execution with live trading credentials.
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
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (10)

Tp4

High
Category
MCP Tool Poisoning
Confidence
93% confidence
Finding

There is a material description-behavior mismatch. The declared purpose describes a broad OKX trading skill centered on REST API v5 operations such as account balance queries, order placement/cancellation, positions, and market data. The supplied code instead implements a WebSocket client example: public ticker subscriptions and private order-update subscriptions after WebSocket login. While both relate to OKX and market/order data, the primary behavior is real-time streaming/monitoring, not REST-based account and order management. Key declared capabilities like querying balances, placing orders, canceling orders, and checking positions are absent.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
89% confidence
Finding

The README explicitly states the skill can access accounts and place/amend/cancel orders, and later documents how to configure live API credentials, but it does not prominently warn that using the skill can trigger real, account-impacting trades. In an agent-skill context, this omission is dangerous because users may assume operations are informational while the agent is capable of authenticated trading actions against a live exchange account.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The README explicitly states that the skill can place and cancel OKX orders and that the agent will generate authenticated API calls, but it does not prominently warn that this may affect real funds when demo mode is not enabled. In an agent skill context, this omission is dangerous because users may treat examples as safe defaults and unknowingly allow live trades or cancellations on a production exchange account.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The configuration section says that omitting OKX_DEMO or setting it to 0 uses production trading, but it presents this as a normal configuration detail rather than a hazardous mode switch. Because OpenClaw injects these credentials into agent sessions automatically, a misconfigured environment can cause an agent to interact with a live exchange account without an adequate warning barrier.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The example for place-order.py demonstrates trade execution with only a brief note about simulated trading, but it does not clearly warn that changing environment settings or using production credentials can submit a real order. In an agent ecosystem, runnable examples are often copied verbatim, so insufficient warning materially increases the chance of accidental real-market actions.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium
Category
MCP Least Privilege
Confidence
91% confidence
Finding

The skill explicitly instructs storing API credentials in environment variables and describes making authenticated network requests, but it does not declare any tool scope or permission boundary. That creates a least-privilege and transparency problem: an agent or reviewer cannot easily tell that the skill needs secret access and outbound network capability, increasing the chance of unintended credential exposure or unauthorized live API actions.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
89% confidence
Finding

The skill gives concrete guidance for placing and cancelling real exchange orders and notes that live trading is possible by removing the demo flag, but it does not prominently warn about irreversible financial loss or require a safe default workflow. In an agent setting, this increases the risk of accidental execution of real-money trades with user credentials.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The module docstring frames the script as narrowly focused on placing a limit buy order on OKX. In reality, the file includes a separate cancel_order capability and CLI arguments that permit sell, market, post-only, FOK, and IOC orders, which is broader behavior than the documentation claims.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The top-level docstring explicitly states 'Place a limit buy order on OKX,' which implies a single constrained action. However, the implementation accepts arbitrary side and ordType values and defines a cancellation function, so the inline documentation is contradictory rather than merely incomplete.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

This reference documents live trading operations such as placing, canceling, and amending orders without any caution that these actions can execute against real funds and create financial loss. In the context of an agent skill that may guide or trigger OKX trading workflows, omission of risk and live-trading warnings increases the chance of accidental or uninformed destructive actions by users or downstream agents.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.