Back to skill

Security audit

OKX Exchange

Security checks for vulnerabilities and agentic risk

Overview

This is a real OKX trading skill, but it needs Review because it can handle live credentials, execute automated trades, and install scheduled jobs with incomplete safety boundaries.

Install only if you are comfortable with a Review-level trading skill: use demo mode first, use withdrawal-disabled and IP-restricted OKX keys, avoid setting `OKX_API_URL`, lock down `.env` permissions, keep `auto_trade` and `--no-confirm` off unless you have independent limits, and review cron jobs before enabling scheduled monitoring.

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

T09 · Insecure Skill Coding Practices

Error
Location
scripts/okx_client.py:28
Finding
Authenticated REST requests can be redirected to an arbitrary server<![CDATA[ ## Vulnerability Details **File Location**: `scripts/okx_client.py`, lines 28 and 76–101 **Vulnerability Type**: Unvalidated authenticated API endpoint override **Risk Level**: High ### Vulnerable Code ```python BASE_URL = os.getenv("OKX_API_URL", "https://www.okx.com") ``` ```python def _headers(self, method: str, path: str, body: str = "") -> dict: ts = _timestamp() return { "OK-ACCESS-KEY": self.api_key, "OK-ACCESS-SIGN": _sign(ts, method, path, body, self.secret), "OK-ACCESS-TIMESTAMP": ts, "OK-ACCESS-PASSPHRASE": self.passphrase, "OK-ACCESS-SBE": "0", "x-simulated-trading": "1" if self.simulated else "0", "Content-Type": "application/json", } def _request(self, method: str, full_path: str, data: str = None) -> dict: url = BASE_URL + full_path _retryable = ( requests.exceptions.SSLError, requests.exceptions.ConnectionError, requests.exceptions.Timeout, ) for attempt in range(3): try: headers = self._headers(method, full_path, data or "") if method == "GET": r = requests.get(url, headers=headers, timeout=10) else: r = requests.post(url, headers=headers, data=data, timeout=10) ``` ### Technical Analysis The API origin is controlled by the `OKX_API_URL` environment variable without validation of its scheme, hostname, port, or resolved address. All authenticated REST requests use this origin while including the OKX API key, passphrase, timestamp, and HMAC signature in request headers. The base64 operation used for `OK-ACCESS-SIGN` is legitimate HMAC encoding rather than covert obfuscation. However, because the resulting authentication data is sent to an unrestricted destination, a malicious or accidentally modified environment can redirect it away from OKX. The API secret itself is not directly transmitted. Nevertheless, an attacker-controlled endpoint receives: ...[truncated 1573 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `OKX_API_URL` configurability unless it is operationally necessary. 2. Maintain an exact allowlist of approved origins, for example: - `https://www.okx.com` 3. Parse the URL with `urllib.parse.urlparse` and require: - HTTPS - An exact allowlisted hostname - An approved port - No embedded username or password 4. Refuse to attach authentication headers when the destination is not allowlisted. 5. Consider separate fixed clients for public and authenticated endpoints. 6. Prevent redirects on authenticated requests or verify every redirect destination before forwarding authentication headers. 7. Document any supported regional OKX origins explicitly rather than accepting arbitrary values. 8. Add tests proving that HTTP, unapproved domains, deceptive subdomains, and user-info URL forms are rejected. ]]>

T08 · Insecure Dependencies

Warning
Location
scripts/setup.py:7
Finding
Setup automatically installs unpinned third-party packages<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup.py`, lines 7–17; `requirements.txt`, line 1 **Vulnerability Type**: Mutable and unpinned dependency installation **Risk Level**: Medium ### Vulnerable Code ```python def check_deps(): required = ["requests", "websocket-client"] missing = [] for pkg in required: try: __import__(pkg) except ImportError: missing.append(pkg) if missing: print(f"Installing: {', '.join(missing)}") subprocess.check_call([sys.executable, "-m", "pip", "install"] + missing, stdout=subprocess.DEVNULL) print("Done.") ``` The dependency manifest contains only: ```text requests>=2.31.0 ``` ### Technical Analysis The documented setup program invokes pip automatically when a dependency is missing. Package names are not pinned to exact versions, package hashes are not verified, and the selected package index is inherited from the user's pip configuration and environment. `websocket-client` is installed by the setup script but is absent from `requirements.txt`. The `requests` dependency has only a lower version bound, allowing future releases to be installed without review. Although the package names are established packages and no typosquatting was identified, the installation process is mutable. Running setup can therefore execute package installation code that was not part of the audited Skill artifact. ### Attack Path 1. The user follows the documented setup process: ```bash python setup.py ``` 2. `requests` or `websocket-client` is absent from the active Python environment. 3. `setup.py` invokes: ```bash python -m pip install requests websocket-client ``` 4. Pip resolves packages using mutable index state and local pip configuration. 5. A compromised package release, package index, mirror, or dependency can supply malicious installation or runtime code. 6. That code executes with the privileges of the user running set ...[truncated 528 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin every direct dependency to an exact audited version. 2. Include `websocket-client` in the dependency manifest. 3. Generate a lock file containing all transitive dependencies. 4. Require hashes, such as through: ```bash pip install --require-hashes -r requirements.txt ``` 5. Avoid installing packages automatically from application code. 6. Instruct users to create an isolated virtual environment and install dependencies explicitly. 7. Use a trusted, HTTPS-protected package index and prevent untrusted pip configuration from silently changing the source. 8. Add automated dependency vulnerability and integrity scanning to release procedures. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:24
Finding
Credential setup stores exchange secrets without enforcing restrictive permissions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 24–31 **Vulnerability Type**: Insecure plaintext credential-file creation **Risk Level**: Medium ### Vulnerable Code ```bash # 1. Add credentials to .env cat >> ~/.openclaw/workspace/.env << 'EOF' OKX_API_KEY=your_key OKX_SECRET_KEY=your_secret OKX_PASSPHRASE=your_passphrase OKX_SIMULATED=1 EOF ``` Equivalent setup instructions also appear in `README.md` and `README_ZH.md`. ### Technical Analysis The Skill legitimately requires OKX credentials to perform its declared account-management and trading functions. Reading those credentials is therefore functionally necessary. However, the documented setup command appends credentials to a plaintext file without: - Creating the file with mode `0600` - Applying `chmod 600` - Verifying file ownership - Checking whether the file is a symbolic link - Warning when the existing file is group- or world-readable - Preventing duplicate or obsolete credential definitions The resulting permissions depend on the user's umask or the permissions of a pre-existing file. The programmatic readers in `scripts/setup.py` and `scripts/okx_client.py` also consume the file without validating its owner or permissions. ### Attack Path 1. The user follows the documented `cat >>` setup command. 2. The file is newly created under a permissive umask, or an existing file already has weak permissions. 3. Demo or live OKX API credentials remain in plaintext in the file. 4. Another local user or compromised process with read access obtains the credentials. 5. The credentials are used against the OKX API within the permissions granted to the key. A separate local attack is possible if an attacker can pre-create the target as a symbolic link, causing the shell append operation to write credential text to another writable target. ### Impact Assessment Exposure can grant the attacker the exchange privileges assigned to the affected API key. Depending on key configuration, ...[truncated 378 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Create the credential file securely before writing: ```bash install -m 600 /dev/null ~/.openclaw/workspace/.env ``` 2. Verify that the file is owned by the current user and is not a symbolic link. 3. Apply and verify restrictive permissions: ```bash chmod 600 ~/.openclaw/workspace/.env ``` 4. Set a restrictive umask during credential setup: ```bash umask 077 ``` 5. Update `setup.py` and `okx_client.py` to reject or prominently warn about unsafe ownership and permissions. 6. Prefer a platform secret manager or OS keyring over a shared plaintext workspace file. 7. Require dedicated API keys with: - Withdrawal permission disabled - Minimal trading/account permissions - IP allowlisting where supported - Separate demo and live credentials 8. Replace append-based setup with an idempotent configuration process that detects duplicate keys and avoids retaining obsolete secrets. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
scripts/execute.py:34
Finding
Configured derivative position limits are not enforced during order placement<![CDATA[ ## Vulnerability Details **File Location**: `scripts/execute.py`, lines 34–46 **Vulnerability Type**: Missing notional and position-limit enforcement for derivatives **Risk Level**: High ### Vulnerable Code ```python def place_order(inst_id: str, side: str, ord_type: str, sz: str, td_mode: str = "cash", px: str = "", pos_side: str = "", reduce_only: bool = False, tp: str = "", sl: str = "", no_confirm: bool = False) -> None: prefs = load_prefs() client = OKXClient() # Max order USD check (spot only; derivatives rely on leverage limit) if td_mode == "cash": ticker = client.ticker(inst_id) if ticker.get("code") == "0": price = float(ticker["data"][0].get("last", 0)) order_usd = float(sz) * price max_usd = prefs.get("max_order_usd", 100) if order_usd > max_usd: log.error(f"Aborted: order value ${order_usd:.2f} exceeds max_order_usd=${max_usd}") return ``` The declared configuration includes a position limit: ```python DEFAULT_PREFS: dict = { "max_order_usd": 100, "max_leverage": 10, "price_impact_warn": 0.005, "price_impact_abort": 0.01, "require_confirm": True, "stop_loss_pct": 5.0, "take_profit_pct": 10.0, "auto_trade": False, "max_position_usd": 100, "max_daily_trades": 10, } ``` ### Technical Analysis The maximum order-value check is explicitly limited to `td_mode == "cash"`. Swap and futures orders using `cross` or `isolated` mode bypass this control. Although leverage is limited elsewhere, a leverage ceiling does not cap order notional or total position exposure. The configured `max_position_usd` value is not consulted by `place_order()`, and the code does not calculate the post-trade derivative position. The remaining confirmation safeguard can be bypassed through the documented `--no-confirm` option. Consequently, live derivative orders can e ...[truncated 1326 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Enforce order-notional limits for spot, swaps, and futures. 2. Retrieve instrument metadata and calculate derivative notional using the correct contract value, multiplier, settlement currency, and mark price. 3. Fetch current positions and calculate projected post-order exposure before submission. 4. Reject any order that would exceed `max_order_usd` or `max_position_usd`. 5. Fail closed when price, instrument metadata, position data, or order-book data cannot be obtained. 6. Apply limits to batch orders, grid strategies, arbitrage legs, monitoring automation, and direct `OKXClient` order paths—not only the unified CLI. 7. Treat reduce-only orders separately so genuine exposure reduction is not incorrectly blocked. 8. Require explicit interactive confirmation for live orders above a conservative threshold, even when general automation is enabled. 9. Introduce additional controls such as: - Maximum aggregate account exposure - Maximum margin usage - Maximum per-instrument exposure - Daily realized-loss limits - Maximum number of open orders 10. Add tests covering oversized cross-margin and isolated-margin orders, existing-position aggregation, contract multipliers, and `--no-confirm`. ]]>
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Taint TrackingDirect Taint Flow, Variable-Mediated Taint Flow, Credential Exfiltration Chain
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (101)

Tainted flow: 'BASE_URL' from os.getenv (line 28, credential/environment) → requests.get (network output)

Critical
Category
Data Flow
Content
if time.time() - _last_sync < 300:
        return
    try:
        r = requests.get(f"{BASE_URL}/api/v5/public/time", timeout=5)
        server_ms = int(r.json()["data"][0]["ts"])
        _time_offset = server_ms / 1000 - time.time()
        _last_sync = time.time()
Confidence
95% confidence
Finding
The client builds outbound request destinations from OKX_API_URL, which is loaded from environment data that itself may be populated from a local .env file. If an attacker can influence that environment variable or file, they can redirect authenticated requests to an attacker-controlled server and exfiltrate API key, passphrase, signed timestamps, and trading intent metadata; in this trading context, that can enable account compromise or destructive market actions.

Tainted flow: 'url' from os.getenv (line 88, credential/environment) → requests.get (network output)

Critical
Category
Data Flow
Content
try:
                headers = self._headers(method, full_path, data or "")
                if method == "GET":
                    r = requests.get(url, headers=headers, timeout=10)
                else:
                    r = requests.post(url, headers=headers, data=data, timeout=10)
                if not r.ok:
Confidence
99% confidence
Finding
Authenticated GET requests are sent to a URL derived from BASE_URL, and the headers include OKX credentials and HMAC signatures. If BASE_URL is attacker-controlled, the client will transmit sensitive authentication material and account data requests to an arbitrary endpoint, effectively creating an SSRF-plus-secret-exfiltration path with direct financial risk.

Tainted flow: 'url' from os.getenv (line 88, credential/environment) → requests.post (network output)

Critical
Category
Data Flow
Content
if method == "GET":
                    r = requests.get(url, headers=headers, timeout=10)
                else:
                    r = requests.post(url, headers=headers, data=data, timeout=10)
                if not r.ok:
                    try:
                        err = r.json()
Confidence
99% confidence
Finding
Authenticated POST requests, including order placement, amendments, cancellation, leverage changes, and transfers, are sent to a URL derived from environment-controlled BASE_URL. In a crypto trading skill, this is especially dangerous because a malicious endpoint can capture credentials and receive highly sensitive trade instructions, leading to theft, unauthorized transfers, and account takeover.

Tp4

High
Category
MCP Tool Poisoning
Confidence
91% confidence
Finding
The description presents a full OKX trading agent capable of querying markets, managing accounts, executing orders, running automated strategies, and handling advanced order/risk features. The supplied code is much narrower: it is a standalone Python decision engine that reads and writes local JSON memory files, applies simple heuristics (RSI, signal, market regime, prior lessons/patterns), simulates expected outcomes from historical journal entries, and logs decisions. There is no networking, no OKX client, no authentication, no exchange resource access, and no live trading or alerting functionality. This is a material description-behavior mismatch because the primary declared purpose is a live exchange trading agent, while the actual behavior is offline advisory analysis and logging.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The description presents a full OKX trading agent with live exchange functions: querying prices, checking balances/positions, placing and managing orders, running trading strategies, and issuing liquidation alerts. The supplied code does something materially narrower and different: it is an offline/local learning and journaling component. It reads and writes JSON files under a memory directory, records completed trade metadata, updates performance statistics, derives lessons from PnL outcomes, classifies simple patterns, cleans/compresses stored history, and offers optimization suggestions. While some parts loosely relate to risk management/performance analysis, the primary declared purpose of an OKX trading agent is not implemented. The code neither accesses OKX nor any network resource, and none of the live trading/account/order capabilities in the description are present.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description presents an end-user OKX trading agent with live trading, account management, strategy execution, risk controls, and trading-related triggers. The supplied code does not implement any of those runtime trading capabilities. Instead, it is a development utility that runs automated tests and optional benchmarks. While the benchmarks reference trading-related components, this script’s actual purpose is test orchestration, which is materially different from the declared operational trading agent behavior.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The supplied code does not implement an OKX trading agent or any of the declared user-facing capabilities. It is strictly a test module validating a separate config module’s file-based persistence behavior: defaults, JSON roundtrips, trade journal appends, grid state filename generation, and equity snapshot retention. While such config testing could support a trading system, this chunk’s actual purpose is materially different from the declared description. Therefore, the description does not accurately represent what this code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The declared description presents a full-featured OKX trading agent with operational trading, exchange interactions, and risk/alert capabilities. The actual code chunk is a test module (`scripts/tests/test_decision.py`) that validates behavior of a `DecisionEngine` class. Its scope is limited to testing internal decision-making helpers: checking avoid/success patterns, generating buy/sell/wait decisions, logging decisions, summarizing logs, and simulating scenarios from historical journal data. There are no API calls to OKX, no market data fetching, no account balance or position handling, no order placement/cancellation, no strategy scheduler/automation, and no liquidation monitoring. This is a materially different primary purpose from the declared skill behavior, so it is a mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The supplied code does not implement the declared trading-agent functionality. It is strictly a unit test module for error definitions in an OKX-related codebase. While such tests may be a supporting component of a larger trading system, this specific chunk neither queries market data nor manages accounts, places orders, runs strategies, performs risk checks, or emits reports/alerts. Therefore the description materially overstates and misrepresents what this code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding
There is a material mismatch between the declared description and the actual code chunk. The description presents a full-featured OKX quantitative trading agent spanning multiple instruments and strategy/risk/reporting capabilities. The provided code, however, is only a test module for grid-related functionality. It uses mocks and assertions to validate calculations, order-placement constraints, state-file structure, and order cancellation behavior. While grid trading is one of the declared strategies, this chunk does not itself provide the broad operational capabilities claimed, and its primary purpose is testing, not acting as a user-facing trading agent. Therefore the description does not accurately represent what this supplied code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The declared description presents a full OKX trading agent capable of interacting with exchange data, accounts, positions, and orders. The provided code chunk does not implement or expose those behaviors; instead, it is strictly a unit test file for a local analytics/learning component. It manipulates temporary file paths and validates functions related to recording historical trade outcomes, lessons learned, patterns, and cleanup. While some tested concepts loosely support trading strategy/risk/performance reporting, the actual code chunk has a materially different immediate purpose and lacks the core exchange-facing capabilities central to the description.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The supplied code is clearly a test module, not an operational trading agent. Its primary function is to verify behavior of an OKX private WebSocket feed and related client caching logic: authentication payload construction, channel subscriptions, message parsing, account/position/order cache updates, REST fallback, and thread safety. These behaviors are related to a subset of the declared domain—account/portfolio state monitoring on OKX—but they do not match the broad declared description of a full quantitative trading agent with execution, strategies, risk controls, reports, and alerts. There is no evidence here of placing trades, generating strategy signals, managing stop loss/take profit, liquidation monitoring, or querying public market prices. Therefore the description materially overstates what this code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The supplied code is strictly a test module for a reporting component (`test_report.py`). Its behavior is limited to validating performance-report logic such as win/loss stats, coin-level PnL aggregation, date-range filtering, and generation of textual report output from local journal files. While performance reporting is one capability mentioned in the description, the overall declared purpose is a full OKX quantitative trading agent with broad trading and account capabilities. None of those primary capabilities are present in this code chunk. Therefore the description materially overstates what this code actually does, making it a mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding
The supplied code is only a test module (scripts/tests/test_trend.py). Its actual purpose is validating indicator calculations and trend signal logic with mocked OKX client responses. While this loosely relates to one small part of the declared description—trend-following signal analysis and market-data-based analysis—it does not implement the broad trading-agent capabilities claimed in the description. There is no real account access, no order placement, no portfolio management, no arbitrage/grid execution, no risk or liquidation monitoring, and no reporting. Therefore the declared description materially overstates what this code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
There is a clear description-behavior mismatch. The declared purpose describes a full-featured OKX quantitative trading agent with trading, portfolio, strategy, risk, and alerting capabilities. The actual code chunk is only a test file focused on validating WebSocket feed caching and transparent WS/REST switching for ticker and candle market data, plus subscription and thread-safety behavior. While this is related to OKX market-data infrastructure, it is only a small supporting component and does not substantiate the broad trading-agent functionality claimed in the description.

Credential Access

High
Category
Privilege Escalation
Content
## Setup (First Time)

```bash
# 1. Add credentials to .env
cat >> ~/.openclaw/workspace/.env << 'EOF'
OKX_API_KEY=your_key
OKX_SECRET_KEY=your_secret
Confidence
91% confidence
Finding
The skill instructs users to place exchange API credentials in a workspace `.env` file and later load them into the shell environment. Handling secrets is expected for an exchange client, but documenting credential storage and shell sourcing in a broadly scoped skill increases the blast radius if the agent, other skills, or logs can read environment variables or workspace files.

Credential Access

High
Category
Privilege Escalation
Content
```bash
# 1. Add credentials to .env
cat >> ~/.openclaw/workspace/.env << 'EOF'
OKX_API_KEY=your_key
OKX_SECRET_KEY=your_secret
OKX_PASSPHRASE=your_passphrase
Confidence
91% confidence
Finding
This line continues the secret-handling pattern by instructing storage of API key material in plaintext configuration. In a skill with shell/file capabilities, plaintext credentials become attractive targets for accidental disclosure or abuse.

Credential Access

High
Category
Privilege Escalation
Content
On every session, load credentials first:
```bash
source ~/.openclaw/workspace/.env
cd ~/.openclaw/workspace/skills/okx-exchange/scripts
```
Confidence
94% confidence
Finding
The session-init instructions explicitly `source` the `.env` file, importing exchange credentials into the process environment before running commands. In an agent ecosystem, loaded environment secrets may be exposed to subprocesses, debugging output, or other tooling, making this more sensitive than ordinary local CLI usage.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
Skip confirmation prompt (for automation):
```bash
python3 okx.py buy BTC-USDT market 0.01 --no-confirm
```

## Algo Orders (Standalone TP/SL — for existing positions)
Confidence
96% confidence
Finding
The `--no-confirm` parameter is a high-risk tool option because it suppresses an approval checkpoint on a state-changing action. In this context, parameter abuse can turn a benign request or ambiguous trigger into an immediate live trade with financial consequences.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
## Safety Rules

1. **Always confirm before placing orders** unless `auto_trade=true` or `--no-confirm`
2. **Price impact check**: abort if >1%, warn if >0.5%
3. **Start with `OKX_SIMULATED=1`** — validate everything before going live
4. **Never print or log credentials** — load via `source .env` only
Confidence
95% confidence
Finding
The safety section normalizes use of `--no-confirm`, effectively endorsing a dangerous parameter that defeats an important safeguard. Because the skill targets trading and fund movement, this increases the likelihood of harmful misuse through automation or prompt confusion.

Missing User Warnings

High
Confidence
97% confidence
Finding
The integration example directly wires model output to automatic trade execution when confidence exceeds a threshold, with no user confirmation, policy gate, sanity checks, exposure limits, or fail-safe validation of parameters. In a live crypto trading skill handling leveraged products, this creates a clear pathway for unsafe autonomous execution that could rapidly cause substantial financial losses if the decision engine is wrong, manipulated by bad inputs, or operating on stale data.

Credential Access

High
Category
Privilege Escalation
Content
--target isolated \
      --message "你是 OKX 交易监控 Agent。执行以下命令并将输出原文发送,不要增删任何内容:

source ~/.openclaw/workspace/.env
cd ${SCRIPTS_DIR}
python3 okx.py snapshot
python3 okx.py monitor sl-tp
Confidence
90% confidence
Finding
The cron job instructs an agent to source ~/.openclaw/workspace/.env and then send command output verbatim. In a trading skill context, that environment file is likely to contain API keys, secrets, or account credentials, and any downstream command error, debug output, or accidental echoing of environment-derived values could expose sensitive credentials through the agent's reported output.

Credential Access

High
Category
Privilege Escalation
Content
--target isolated \
      --message "你是 OKX 策略扫描 Agent。执行以下命令并将输出原文发送:

source ~/.openclaw/workspace/.env
cd ${SCRIPTS_DIR}
python3 okx.py monitor scan
Confidence
90% confidence
Finding
This strategy-scan cron job has the same risky pattern: it loads ~/.openclaw/workspace/.env and instructs the agent to return raw command output. Because the skill manages exchange activity and portfolio data, the context increases severity: exposed environment variables or credential-derived errors could leak trading API secrets and enable unauthorized account access or market actions.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
parser.add_argument("--tp", default="", help="Take profit trigger price")
    parser.add_argument("--sl", default="", help="Stop loss trigger price")
    parser.add_argument("--reduce", action="store_true")
    parser.add_argument("--no-confirm", action="store_true")
    args = parser.parse_args()

    if args.action in ("buy", "sell"):
Confidence
91% confidence
Finding
The same --no-confirm parameter is a tool-parameter abuse risk because any caller that can influence CLI arguments can bypass the primary human safety control. In a trading environment, that can turn otherwise reviewable order placement into immediate execution, magnifying losses from prompt injection, orchestration mistakes, or unauthorized automation.

Missing User Warnings

High
Confidence
95% confidence
Finding
The monitor can autonomously place live market orders with no user confirmation by calling the execution path with no_confirm=True after a strategy signal. In a trading skill, this is especially dangerous because false signals, stale data, logic bugs, or manipulated inputs can immediately cause irreversible financial loss, and market orders may execute at unfavorable prices during volatility.

Static analysis

No suspicious patterns detected.