Back to skill

Security audit

Stove Maker Api

Security checks for vulnerabilities and agentic risk

Overview

This skill is mostly aligned with a trading API helper, but it handles real financial actions and bearer tokens with several unsafe or under-scoped patterns that should be reviewed before installation.

Install only if you are comfortable giving this skill access to a real Stove Maker JWT and using it for production trading actions. Avoid custom base URLs unless you fully trust the endpoint, do not pass real JWTs in command lines or examples, require explicit confirmation before create/cancel/corporate-action operations, and do not follow the unlimited token-approval or localStorage JWT patterns without safer controls.

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

T09 · Insecure Skill Coding Practices

Error
Location
scripts/maker_api.py:20
Finding
JWT Disclosure Through Unrestricted Custom API Base URL<![CDATA[ ## Vulnerability Details **File Location**: `scripts/maker_api.py:20-45` **Vulnerability Type**: Arbitrary credential destination / insufficient endpoint validation **Risk Level**: High ### Vulnerable Code ```python def build_env_config(env: str, base_url: Optional[str], jwt_token: str) -> EnvConfig: """Resolve final base URL from env / override.""" if not jwt_token: raise SystemExit("jwt_token is required for Maker API calls.") if base_url: return EnvConfig(base_url=base_url.rstrip("/"), jwt_token=jwt_token) if env == "test": return EnvConfig(base_url="https://api-qa.proto.stove.finance", jwt_token=jwt_token) # default: production return EnvConfig(base_url="https://proto.stove.finance", jwt_token=jwt_token) 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("Authorization", f"Bearer {cfg.jwt_token}") return req def http_call(req: request.Request) -> Dict[str, Any]: """Perform HTTP request and return parsed JSON.""" try: with request.urlopen(req, timeout=20) as resp: ``` ### Technical Analysis The `--base-url` override is accepted without validating its scheme, hostname, port, or trust relationship. Every request constructed from this URL receives the user's complete bearer JWT in the `Authorization` header. Consequently, the token can be sent directly to an attacker-controlled domain or over plaintext HTTP. The default production and test destinations are legitimate HTTPS endpoints, and authenticated network traffic is required by the Skill's declared purpose. However, unrestricted credential forwarding to any caller-selected endpoint exceeds the minimum privileges necessary. ...[truncated 1367 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove arbitrary production overrides or restrict them to an explicit allowlist: - `proto.stove.finance` - `api-qa.proto.stove.finance` 2. Require the URL scheme to be exactly `https`. 3. Reject embedded credentials, fragments, unexpected ports, IP literals, and malformed hostnames. 4. Resolve and compare normalized hostnames rather than using suffix matching. 5. Disable redirects or implement a redirect handler that rejects cross-origin and HTTPS-to-HTTP redirects. 6. Do not attach the JWT until the final destination has passed validation. 7. If custom development endpoints are necessary, require a separate explicit unsafe-development flag and do not reuse production JWTs with them. 8. Add tests confirming that HTTP URLs, unapproved domains, deceptive subdomains, and cross-origin redirects are rejected. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/maker_api.py:151
Finding
JWT Exposed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/maker_api.py:151-154` **Related Documentation**: `SKILL.md:66-133` **Vulnerability Type**: Sensitive credential exposure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```python parser.add_argument( "--jwt-token", required=True, help="Maker API JWT Token,将作为 Authorization: Bearer {jwt} 使用。", ) ``` The documented invocation pattern repeatedly instructs users to pass the credential on the command line: ```bash python skills/stove-maker-api/maker_api.py \ --env prod \ --jwt-token YOUR_JWT \ orders \ --ticker AAPL ``` ### Technical Analysis Command-line arguments are not an appropriate transport for bearer credentials. Depending on the host environment, process arguments may be exposed through: - Process inspection facilities. - Shell history files. - Terminal session recording. - CI/CD and orchestration logs. - Agent tool-call telemetry. - Debug output or support bundles. Although the Skill instructs the Agent not to repeat the JWT in logs or answers, its required command-line interface inherently places the token into observable command metadata. This conflicts with the Skill's stated secret-handling requirement. ### Attack Path 1. A user follows the documented command and supplies a real JWT through `--jwt-token`. 2. The command is retained in shell history, Agent execution records, or process metadata. 3. A local user, monitoring process, log reader, or compromised support system reads the argument. 4. The exposed bearer token is replayed against the Maker API. 5. The attacker retains access until token expiration or revocation. ### Impact Assessment The attacker obtains the API authority represented by the JWT. Potential effects include disclosure of orders and positions and unauthorized API operations allowed by the token. This issue does not itself expose the wallet's private key, and actions requiring a separate valid wall ...[truncated 61 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `--jwt-token` as the primary credential input. 2. Prefer, in descending order: - A protected operating-system keyring or secret manager. - A file descriptor or protected file readable only by the current user. - Interactive secret input using Python's `getpass`. - Standard input where execution infrastructure guarantees redaction. 3. If environment-variable support is retained for automation, document its process-environment exposure and use a narrowly named variable such as `STOVE_MAKER_JWT`. 4. Never generate or print shell commands containing the real token. 5. Ensure Agent tool-call logging and CI systems redact JWT-shaped values and authorization headers. 6. Clear references to the token as soon as practical and provide documented token revocation procedures. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
references/API Authorization.md:192
Finding
Authorization Example Persists JWT in Browser localStorage<![CDATA[ ## Vulnerability Details **File Location**: `references/API Authorization.md:192-214` **Vulnerability Type**: Insecure browser token storage **Risk Level**: Medium ### Vulnerable Code ```javascript const API_BASE_URL = process.env.API_BASE_URL; // Set based on environment async function authenticate(walletAddress, chainId, message, signature) { const response = await fetch(`${API_BASE_URL}/api/v1/makers/connect`, { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ wallet_address: walletAddress, chain_id: chainId, message: message, signature: signature, }), }); const data = await response.json(); if (data.code === 0) { // Store JWT token localStorage.setItem('jwt_token', data.data.jwt); return data.data.jwt; } else { throw new Error(data.message || 'Authentication failed'); } } ``` ### Technical Analysis Browser `localStorage` is readable by all JavaScript executing under the same origin. It does not provide the `HttpOnly` protection available to cookies. A cross-site scripting vulnerability, compromised third-party script, or malicious browser extension with relevant access can therefore retrieve the JWT. The document later advises avoiding `localStorage` for sensitive applications, but that warning does not neutralize the risk created by a complete, copyable example that explicitly stores the token there. ### Attack Path 1. A developer copies the provided authentication example into an application. 2. The application persists the Maker JWT in `localStorage`. 3. The application later suffers an XSS issue or loads a compromised same-origin dependency. 4. Malicious JavaScript reads `localStorage.getItem('jwt_token')`. 5. The script sends the JWT to an attacker. 6. The attacker replays the bearer credential against the Maker API. ### Impact Assessment Successful exploitation grants the attacker the API permissions encoded in the stolen JWT. The compromise can expose ...[truncated 226 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the `localStorage.setItem` example rather than relying on a later warning. 2. For browser applications, prefer: - Short-lived tokens stored only in memory, or - `Secure`, `HttpOnly`, and appropriately configured `SameSite` cookies. 3. If cookies are used, implement CSRF defenses appropriate to the API architecture. 4. Apply a restrictive Content Security Policy and avoid unsafe inline scripts. 5. Minimize third-party JavaScript and use integrity controls where applicable. 6. Keep JWT lifetimes short, rotate tokens, and support immediate revocation. 7. Add a secure logout flow that invalidates the server-side session and clears all client-side state. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
references/EIP-712 Order Signature.md:493
Finding
Unlimited ERC-20 Allowance Exceeds Least-Privilege Requirements<![CDATA[ ## Vulnerability Details **File Location**: `references/EIP-712 Order Signature.md:493-504` **Vulnerability Type**: Excessive token spending authorization **Risk Level**: High ### Vulnerable Code ```javascript ### 2. Authorization Check Token authorization is required before creating orders: Buy Order Authorization Sell Order Authorization javascript // Buy order: Authorize USDT/USDC await usdtContract. approve (rfqSettlementAddress, ethers.MaxUint256) ``` In normalized JavaScript form, the recommendation is: ```javascript await usdtContract.approve(rfqSettlementAddress, ethers.MaxUint256) ``` ### Technical Analysis The guide authorizes the settlement contract to spend the maximum possible ERC-20 amount rather than the amount required for a specific order. Approval is necessary for the buy-order workflow, but an unlimited allowance is not the minimum privilege required. ERC-20 allowances generally remain active until changed or revoked. The approval can consequently cover both the user's current balance and tokens received later. If the settlement contract is vulnerable, upgradeable to malicious logic, controlled by compromised privileged keys, or replaced through incorrect address configuration, the approved balance can be transferred without another wallet confirmation. ### Attack Path 1. The user follows the guide and approves `ethers.MaxUint256`. 2. The allowance remains active after the original order is completed or cancelled. 3. The settlement contract, its administrative keys, or the configured contract address becomes compromised or malicious. 4. The authorized spender calls `transferFrom` against the user's token balance. 5. Tokens up to the outstanding unlimited allowance are transferred without a new approval transaction. ### Impact Assessment The spender can potentially transfer all current and future balances of the approved USDT or USDC token from the wallet, subject to the token contract's behavior and the remaining allowa ...[truncated 158 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Approve only the exact amount needed for the current order, including a tightly bounded fee where necessary. 2. If repeated orders require an operational allowance, use a user-selected cap rather than `MaxUint256`. 3. Verify and display the chain ID, token address, spender address, amount, and allowance duration before requesting approval. 4. Source settlement addresses from a signed or otherwise authenticated deployment registry. 5. Recommend revoking unused allowances after order completion or cancellation. 6. Where supported, use permit mechanisms with bounded amounts, explicit deadlines, and nonces. 7. Document the trust and upgrade model of the settlement contract so users can assess the residual allowance risk. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/maker_api.py:126
Finding
Cancellation Command Does Not Match the Bundled API Contract<![CDATA[ ## Vulnerability Details **File Location**: `scripts/maker_api.py:126-132` **Related Specification**: `references/Cancel Order.md:5-29` **Vulnerability Type**: Incorrect implementation of a security-sensitive financial operation **Risk Level**: Medium ### Vulnerable Code ```python def cmd_cancel_order(cfg: EnvConfig, args: argparse.Namespace) -> None: # 具体取消路径以官方文档为准,这里假设为 DELETE /api/v1/orders/{order_hash} path = f"/api/v1/orders/{args.order_hash}" url = f"{cfg.base_url}{path}" req = _build_request(url, "DELETE", cfg) data = http_call(req) json.dump(data, sys.stdout, ensure_ascii=False, indent=2) sys.stdout.write("\n") ``` The bundled cancellation specification instead states: ```text Endpoint: POST /api/v1/orders/{order_id}/cancel ``` Its example is: ```bash curl -X POST "/api/v1/orders/550e8400-e29b-41d4-a716-446655440000/cancel" \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \ -H "Content-Type: application/json" ``` ### Technical Analysis The executable uses a different HTTP method, path, and identifier type than the included authoritative reference: - Script: `DELETE /api/v1/orders/{order_hash}` - Documentation: `POST /api/v1/orders/{order_id}/cancel` The source comment explicitly acknowledges that the endpoint was assumed. Cancellation is a financially sensitive operation, and an assumed endpoint is unsafe. The most likely result is a failed request, but behavior could vary if the server implements a different DELETE route. ### Attack Path 1. A user creates an order and later requests cancellation. 2. The Skill invokes `cancel-order` with an order hash. 3. The script sends a DELETE request to the undocumented endpoint. 4. The server rejects the request or does not cancel the intended order. 5. The user or Agent incorrectly assumes the operational cancellation workflow is valid unless the response is carefully interpreted. 6. The order remains active and may subsequently be ...[truncated 377 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace the assumed operation with the documented contract: - Method: `POST` - Path: `/api/v1/orders/{order_id}/cancel` - Identifier: UUID order ID 2. Rename `--order-hash` to `--order-id` for this command and validate UUID syntax. 3. Check both HTTP status and the response's application-level `code` and `data.success` fields. 4. After cancellation, query the order and verify that it entered the expected terminal state. 5. Clearly report failed or indeterminate cancellation rather than implying success. 6. Add integration tests against both test and production-compatible API schemas. 7. Remove comments and behavior based on endpoint assumptions from security-sensitive transaction operations. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (37)

Tp4

High
Category
MCP Tool Poisoning
Confidence
88% confidence
Finding
整体上,代码确实是在使用 JWT 调用 Stove Protocol Maker API,并管理订单与仓位,因此与声明的大方向基本一致。但声明特别提到“相关实时报价推送”,而实际代码仅实现同步 HTTP 请求的命令行工具,没有 WebSocket、SSE、轮询推送封装或任何实时推送机制,因此描述包含了代码未体现的重要能力,构成描述与行为不完全一致。另一方面,代码还实现了 nonce 查询和手续费估算,这些虽未在描述中点明,但属于订单管理的配套功能,不属于严重偏离。综合判断为存在轻度到中度不匹配。

Missing User Warnings

High
Confidence
97% confidence
Finding
The example recommends approving ethers.MaxUint256 for the settlement contract, which grants effectively unlimited token spending. If the contract is compromised, upgraded maliciously, misconfigured, or the user approves the wrong address/network, all approved funds could be drained; in a trading/institutional context this materially increases risk.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
def cmd_cancel_order(cfg: EnvConfig, args: argparse.Namespace) -> None:
    # 具体取消路径以官方文档为准,这里假设为 DELETE /api/v1/orders/{order_hash}
    path = f"/api/v1/orders/{args.order_hash}"
    url = f"{cfg.base_url}{path}"
    req = _build_request(url, "DELETE", cfg)
Confidence
90% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High
Category
Tool Misuse
Content
# cancel order
    p_cancel = subparsers.add_parser(
        "cancel-order",
        help="取消订单(DELETE /api/v1/orders/{order_hash},具体以文档为准)。",
    )
    p_cancel.add_argument(
        "--order-hash",
Confidence
90% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High
Category
Tool Misuse
Content
# cancel order
    p_cancel = subparsers.add_parser(
        "cancel-order",
        help="取消订单(DELETE /api/v1/orders/{order_hash},具体以文档为准)。",
    )
    p_cancel.add_argument(
        "--order-hash",
Confidence
90% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Natural-Language Policy Violations

Medium
Confidence
95% confidence
Finding
The manifest description is written in Chinese and the operational instructions throughout the file address the agent in Chinese without any opt-in or alternative language guidance. Under the policy, forcing a specific language or locale without user choice is a natural-language policy violation unless it is explicitly justified as region-specific, which is not stated here.

External Transmission

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

### cURL [​](#curl)

```bash
curl -X POST "{API_BASE_URL}/api/v1/makers/connect" \
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
97% confidence
Finding
The example shows persisting the JWT in localStorage without an adjacent warning, despite nearby guidance acknowledging that this is unsafe for sensitive applications. This normalizes an insecure implementation pattern and increases the chance integrators will expose bearer tokens to theft through XSS or other client-side script execution.

Intent-Code Divergence

Medium
Confidence
98% confidence
Finding
The document’s own best-practices section warns against storing JWTs in localStorage, yet the example code does exactly that. Tokens in localStorage are accessible to any JavaScript running in the page, so an XSS bug, compromised dependency, or malicious browser context could steal the JWT and let an attacker impersonate the user until expiry.

Ae4

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

External Transmission

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

```bash
curl -X POST "/api/v1/orders" \
     -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
     -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
91% confidence
Finding
The documentation includes an Authorization header containing a JWT-shaped bearer token in a curl example without any warning that credentials must be placeholders only. Even if truncated, publishing realistic auth material in docs normalizes copying secrets into shared contexts and can lead users to expose live tokens in repos, tickets, or chat.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
This markdown file includes code examples that send a JWT bearer token and later an order plus cryptographic signature to backend endpoints. While the file explains how to perform the calls, it does not warn users that authenticated credentials and signed trading instructions are transmitted over the network, which is a relevant disclosure for a markdown skill description under the missing-warnings rule.

External Transmission

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

```bash
curl -X POST "/api/v1/orders/estimate_charge" \
     -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
     -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
89% confidence
Finding
This markdown file documents an authenticated API call and shows an Authorization header containing a JWT-like bearer token string. The description does not warn users not to paste real tokens into shared shells, logs, or documentation, which is a privacy and credential-handling concern for markdown under the missing user warnings category.

Ae4

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

Missing User Warnings

Medium
Confidence
87% confidence
Finding
This markdown file documents an endpoint that returns personally identifiable information, including email and wallet address, but provides no user warning or privacy disclosure about handling sensitive account data. Under the markdown-file criteria, descriptions should warn when behavior could affect user data or privacy.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The documentation describes authenticated order creation, position management, and trading actions for institutional accounts without any explicit warning that these operations can place real orders, modify positions, or cause financial loss if invoked unintentionally. In an agent skill context with network permission, this increases the chance that an LLM-driven agent could treat these endpoints as routine data APIs and perform account-impacting actions without adequate user confirmation or safety gating.

Ae4

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

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The documentation instructs clients to place the JWT in the WebSocket subprotocol list, which can expose credentials to browser tooling, intermediary logs, reverse proxies, server access logs, or application diagnostics that record negotiated subprotocol values. Because this skill manages institutional trading orders and positions, compromise of a bearer token could allow unauthorized access to sensitive market actions and real-time account data.

Intent-Code Divergence

Medium
Confidence
97% confidence
Finding
The file documents an "Orderbook Data Push" WebSocket feed and all earlier sections describe only `orderbook_update` and `heartbeat` messages. However, the enum table states `order_status_change` as a WebSocket message type, which contradicts the documented behavior of this endpoint and indicates copied or misleading inline documentation.

Description-Behavior Mismatch

Medium
Confidence
94% confidence
Finding
The documented endpoint authorizes processing of a corporate action, which is outside the skill's declared scope of only managing orders, positions, and quote streaming. This scope expansion increases the chance that an agent or user grants network-capable access to higher-impact asset operations they did not expect, enabling unintended or unauthorized financial actions.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The documentation presents a state-changing authorization endpoint for processing a corporate action without clearly warning that the action may be irreversible or financially significant. In an agent setting, this omission can cause unsafe automation or operator misunderstanding, leading to accidental execution of sensitive transactions.

Ae4

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

Missing User Warnings

Medium
Confidence
94% confidence
Finding
This markdown file documents authenticated API use and includes example requests with a Bearer JWT token header. The description does not warn users not to paste real production tokens into shared terminals, logs, or documentation, which is a privacy and credential-handling concern covered by missing user warnings for markdown files.

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/API Authorization.md:254

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/Cancel Order.md:29

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/Create Order.md:58

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/Estimate Order Fee.md:39

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/Get Profile.md:25

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/Get Stock Token Address.md:31

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/Query Maker Positions.md:46

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/Query Next Available Nonce.md:22

File appears to expose a hardcoded API secret or token.

Critical
Code
suspicious.exposed_secret_literal
Location
references/Query Order List.md:100