Back to skill

Security audit

Stove Taker Api

Security checks for vulnerabilities and agentic risk

Overview

This skill appears purpose-built for Stove Taker API use, but it needs review because it can perform live order actions and handles API credentials in ways that could leak them.

Install only if you trust the Stove API environment and will keep credentials tightly controlled. Avoid custom base URLs unless they are verified Stove endpoints, do not pass real API keys directly on the command line or in WebSocket URLs, prefer test credentials first, and require explicit human approval before any lock, unlock, fill, or reject operation.

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/taker_api.py:15
Finding
API Key Can Be Transmitted to an Arbitrary User-Controlled Server<![CDATA[ ## Vulnerability Details **File Location**: `scripts/taker_api.py:15-44` **Vulnerability Type**: Unrestricted credential destination **Risk Level**: High ### Vulnerable Code ```python def build_env_config(env: str, base_url: Optional[str], api_key: str) -> EnvConfig: """Resolve final base URL from env / override.""" if not api_key: raise SystemExit("api_key is required for Taker API calls.") if base_url: return EnvConfig(base_url=base_url.rstrip("/"), api_key=api_key) if env == "test": return EnvConfig(base_url="https://api-qa.proto.stove.finance", api_key=api_key) # default: production return EnvConfig(base_url="https://proto.stove.finance", api_key=api_key) def _build_request( url: str, method: str, cfg: EnvConfig, body: Optional[Dict[str, Any]] = None, ) -> request.Request: if body is not None: data = json.dumps(body).encode("utf-8") else: data = None req = request.Request(url, method=method, data=data) req.add_header("Content-Type", "application/json") req.add_header("X-API-Key", cfg.api_key) return req ``` The unrestricted override is also exposed as a command-line option at `scripts/taker_api.py:176-179`: ```python parser.add_argument( "--base-url", help="可选:自定义 API 根地址,设置后优先生效。", ) ``` ### Technical Analysis The `--base-url` option accepts an arbitrary URL without validating its scheme, hostname, port, or destination. Every request created for the selected URL receives the sensitive `X-API-Key` header. Sending an API key over the network is necessary for the Skill's declared API functionality when the destination is a trusted Stove Protocol service. Allowing the same credential to be sent to an arbitrary destination exceeds that minimum requirement. No controls limit requests to the two documented endpoints: - `https://proto.stove.finance` - `https://api-qa.proto.stove.finance` The implementation also does not explicitl ...[truncated 1733 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `--base-url` unless custom endpoints are essential to the supported functionality. 2. If overrides are required, enforce an explicit hostname allowlist containing only approved Stove Protocol environments. 3. Parse the URL with `urllib.parse.urlsplit` and require: - The `https` scheme. - An exact approved hostname. - No embedded username or password. - An approved port, normally 443. 4. Reject loopback, private, link-local, multicast, and otherwise non-public resolved addresses where custom hosts are supported. 5. Disable redirects or validate every redirect destination before forwarding authentication headers. 6. Do not attach `X-API-Key` until the final request destination has passed validation. 7. Separate production and test credentials and restrict each credential server-side to the minimum necessary API operations. 8. Add tests proving that HTTP URLs, deceptive subdomains, user-information URLs, internal IP addresses, and redirects to untrusted hosts are rejected. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/taker_api.py:181
Finding
Sensitive API Key Is Accepted Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/taker_api.py:181-185` **Vulnerability Type**: Credential exposure through process arguments **Risk Level**: Medium ### Vulnerable Code ```python parser.add_argument( "--api-key", required=True, help="Taker API Key,将作为 X-API-Key 头使用。", ) ``` The documented invocation pattern also encourages direct command-line use, for example at `SKILL.md:62-73`: ```bash python skills/stove-taker-api/taker_api.py \ --env prod \ --api-key YOUR_API_KEY \ orders \ --status locked,partially_filled \ --ticker AAPL \ --exchange 0 \ --page 1 \ --page-size 20 ``` ### Technical Analysis Command-line arguments are not an appropriate transport for long-lived secrets. Depending on the operating system and execution environment, command arguments may be exposed through: - Process inspection utilities. - Process metadata interfaces. - Shell history. - Audit or endpoint-monitoring logs. - CI/CD job output and automation telemetry. - Error reports that record the complete executed command. Although the documentation uses a placeholder, users are expected to replace it with the real key. Marking `api_key` as secret in `SKILL.md` does not protect it once it is inserted into a command argument. ### Attack Path 1. A user follows the documented invocation pattern and places the real API key after `--api-key`. 2. The shell or orchestration platform records the command, or the argument remains visible in process metadata while the request is running. 3. Another local user, administrator, monitoring agent, or party with access to execution logs retrieves the argument. 4. The observer extracts the API key. 5. The observer reuses the credential against the Stove API within its authorized scope. This path requires access to local process information, command history, or collected execution logs; it is not a direct remote compromise by itself. ### Impact Assessment The exposed party obtains the privilege ...[truncated 407 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace `--api-key` with retrieval from a protected environment variable or secret manager. 2. Where environment variables are unsuitable, read the credential from standard input without echoing it. 3. Support file-descriptor-based secret injection for orchestrated environments. 4. Ensure secret files, if supported, require restrictive permissions and are never copied to temporary files. 5. Remove examples that instruct users to place credentials directly in command arguments. 6. Prevent error messages and debug logging from printing the credential or complete authenticated request headers. 7. Rotate any API key known to have been used in exposed shell histories or shared automation logs. 8. Use short-lived, narrowly scoped credentials where the service supports them. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
references/WebSocket Real-time Push.md:112
Finding
WebSocket Documentation Places an API Key in the Request URL<![CDATA[ ## Vulnerability Details **File Location**: `references/WebSocket Real-time Push.md:112-122` **Vulnerability Type**: Credential exposure through URL query parameters **Risk Level**: Medium ### Vulnerable Documentation ```markdown Taker WebSocket connection uses API Key authentication, need to include valid API Key in request header: Authorization: Bearer <your-api-key> For browser environments, since WebSocket doesn't support custom request headers, you can pass API Key as query parameter: ```javascript const ws = new WebSocket( `wss://${host}/ws/taker/v1?types=order_status_change,cancellation_request&api_key=<your-api-key>` ); ``` ``` ### Technical Analysis The documentation explicitly recommends placing a reusable API key in a WebSocket URL query string. URL query strings are frequently captured by systems that do not treat them as secret material, including: - Reverse proxies and load balancers. - Web server access logs. - Network and application monitoring platforms. - Browser developer tools and diagnostic reports. - Error telemetry and support bundles. - Copied or shared connection URLs. TLS protects the URL while it is transmitted over the network, but it does not prevent the browser, endpoint, proxy, server, or monitoring stack from recording the complete URL. This approach exposes a general API credential more broadly than required for establishing a WebSocket connection. ### Attack Path 1. A developer follows the documented browser example. 2. The developer substitutes a valid API key into the `api_key` query parameter. 3. The browser opens the WebSocket connection using a URL containing the credential. 4. A proxy, server, monitoring system, diagnostic tool, or application log stores the complete URL. 5. A person with access to that stored data extracts the API key. 6. The person reuses the key against the WebSocket or HTTP Taker API. Exploitation requires access to a component or record that captures the URL. ### Impact Asses ...[truncated 491 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not place a reusable API key in a WebSocket URL. 2. For non-browser clients, use the supported authorization header over `wss`. 3. For browser clients, introduce a short-lived, single-purpose WebSocket ticket: - Obtain the ticket through an authenticated HTTPS request. - Scope it only to the required event types and tenant. - Give it a short expiration time. - Make it single-use where practical. 4. Redact authentication query parameters from proxy, server, monitoring, and application logs. 5. Configure referrer, telemetry, and support tooling not to retain complete authenticated URLs. 6. Separate WebSocket credentials from credentials authorized to perform order mutations. 7. Update all examples to use placeholders for short-lived tickets rather than long-lived API keys. 8. Rotate any reusable credentials previously exposed in URL logs. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (21)

Missing User Warnings

Medium
Confidence
83% confidence
Finding
This markdown file includes executable client examples that send authenticated HTTP requests using an API key and secret-derived signature, but the examples section itself does not warn readers that these requests use sensitive credentials and should only be run with securely stored secrets. Although later best-practices mention secure storage, the operational examples can be copied directly without an adjacent disclosure about credential exposure or use in real environments.

External Transmission

Medium
Category
Data Exfiltration
Content
### Lock Order [​](#lock-order)

```bash
curl -X POST "{API_BASE_URL}/api/v1/orders/lock" \
     -H "X-API-Key: YOUR_API_KEY" \
     -H "X-API-Timestamp: 1715100000000" \
     -H "X-API-Signature: GENERATED_SIGNATURE" \
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The troubleshooting section recommends logging the signature string before hashing, but that string contains the full signed request material, including potentially sensitive body contents and authentication-related metadata. Such logs can expose order details, identifiers, and reusable debugging context to anyone with log access, increasing the risk of credential abuse or sensitive data disclosure.

External Transmission

Medium
Category
Data Exfiltration
Content
### Cancellation Success [​](#cancellation-success)

```bash
curl -X POST "/api/v1/orders/cancel-result" \
     -H "X-API-Key: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The documentation describes an order-fill endpoint but does not clearly warn that invoking it executes a live transaction that can transfer or commit assets. In a trading/API skill, this omission can cause users or downstream agents to treat the call as informational rather than state-changing, increasing the risk of unintended fills and financial loss.

External Transmission

Medium
Category
Data Exfiltration
Content
## Request Example [​](#request-example)

```bash
curl -X POST "/api/v1/orders/fill" \
     -H "X-API-Key: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
## Request Example [​](#request-example)

```bash
curl -X POST "/api/v1/orders/lock" \
     -H "X-API-Key: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Ae4

Medium
Category
analysis-evasion
Confidence
80% confidence
Finding
Suspicious Unicode normalization or mixed-script content

Missing User Warnings

Medium
Confidence
90% confidence
Finding
This documentation describes a state-changing unlock operation that affects order control, but it does not include an explicit caution about operational risk, authorization expectations, concurrency effects, or when an agent should require user confirmation before invoking it. In an agent skill with network permission and trading-related actions, omission of such safeguards can lead to unintended order release, race conditions with other takers, or accidental disruption of trading workflows.

External Transmission

Medium
Category
Data Exfiltration
Content
## Request Example [​](#request-example)

```bash
curl -X POST "/api/v1/orders/unlock" \
     -H "X-API-Key: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
## Request Example [​](#request-example)

```bash
curl -X POST "/api/v1/orders/validate" \
     -H "X-API-Key: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The documentation explicitly recommends passing the API key in the WebSocket URL query string for browser clients. Query-string credentials are commonly exposed through browser history, logs, monitoring systems, reverse proxies, analytics tooling, and accidental sharing, which increases the chance of API key compromise. In this skill context, the key grants authenticated access to Taker order events and likely related trading operations, so leakage can expose sensitive order flow and enable unauthorized actions depending on API scope.

Missing User Warnings

Medium
Confidence
86% confidence
Finding
The lock, unlock, fill, and reject commands perform state-changing POST requests that can affect live orders, but the code provides no confirmation prompt or runtime warning before sending them. While the parser help names the endpoints, there is no explicit disclosure that these actions may have irreversible trading or order-management effects, especially in the default production environment.

Intent-Code Divergence

Low
Confidence
95% confidence
Finding
The documentation explicitly instructs developers to avoid hardcoding API keys and secrets, yet the sample code later assigns `api_key` and `api_secret` directly in code variables. Even though the values are placeholders, this is a direct contradiction between the guidance and the demonstrated implementation pattern.

Missing User Warnings

Low
Confidence
81% confidence
Finding
The document states that the endpoint uses API key authentication and later shows the key being sent in a request example, but it does not include any user-facing warning about safeguarding the credential or avoiding accidental exposure. For markdown files, omission of warnings about behaviors affecting privacy or system integrity can qualify as a missing user warning.

Missing User Warnings

Low
Confidence
80% confidence
Finding
This markdown file documents use of an API key and includes a request example that sends the credential in a header, but it does not include any warning about protecting the key or avoiding exposure in shared logs, terminals, or code snippets. For markdown files, SQP-2 applies when descriptions omit warnings about behaviors that could affect privacy or system integrity.

Missing User Warnings

Low
Confidence
88% confidence
Finding
This markdown file documents use of an API key and includes an example request that sends the credential in a header, but it does not include any warning about protecting the key or avoiding exposure in shared terminals, logs, or screenshots. For markdown files, credential-related behavior that can affect privacy or system integrity should include a user-facing warning.

Missing User Warnings

Low
Confidence
82% confidence
Finding
This markdown file includes a request example that uses an `X-API-Key` header, but the surrounding documentation does not warn users to avoid exposing, logging, or hardcoding credentials. For markdown files, credential-handling behavior that could affect privacy or account security should include a user-facing warning.

Missing User Warnings

Low
Confidence
78% confidence
Finding
This markdown file documents authenticated GET endpoints and includes example requests with an `X-API-Key` header, but it does not include any user-facing warning about handling API credentials or the potentially sensitive order/account data returned by the endpoints. Under the markdown criteria for missing warnings, documentation should disclose behaviors that may affect privacy or data exposure.

Description-Behavior Mismatch

Low
Confidence
87% confidence
Finding
The manifest description says the skill is for lock, fill, reject responses and for fill/order queries via the Stove Taker API, but the code also implements a separate order validation operation. Validation is an additional API capability not described in the manifest's stated scope.

Natural-Language Policy Violations

Low
Confidence
94% confidence
Finding
Most user-facing help strings for arguments and subcommands are written only in Chinese, while the tool description and code are otherwise not documented as China-only or locale-specific. This imposes a language choice on users without opt-in or explanation, which matches the language/locale policy concern.

Static analysis

No suspicious patterns detected.