Quant Trading Api

• Outcome: Review
• Latest audit: Sep 14, 2026 · 11:14 PM UTC
• Version: 1.0.0

Overview

This skill presents itself as a real Chinese securities trading integration, but the bundled implementation is a simulator that accepts broker credentials and returns fabricated trading results.

Review this carefully before installing. Treat it as simulation code only unless the publisher clearly documents and implements real broker authentication, paper/live separation, credential handling, order confirmation, risk limits, and authoritative broker reconciliation. Do not provide production broker credentials to this version.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:65
• Finding: Unpinned and Unnecessary Third-Party Dependencies<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 65 **Vulnerability Type**: Uncontrolled third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash pip install requests pycryptodome websocket-client ``` ### Technical Analysis The installation instructions retrieve the latest available versions of three packages without version constraints, integrity hashes, or a lockfile. Consequently, the exact code installed can change after the skill has been reviewed. The supplied implementation does not use `pycryptodome` or `websocket-client`. Although `requests` is imported, no request is made with it. These unnecessary dependencies expand the supply-chain attack surface without providing functionality. This issue does not establish that the named packages are currently malicious. It creates exposure to compromised package releases, malicious dependency substitution in an untrusted package index, and unexpected breaking or vulnerable future releases. ### Attack Path 1. A user follows the installation command in `SKILL.md`. 2. `pip` resolves the current package versions from its configured package index. 3. An attacker compromises a future dependency release or controls an index configured in the user's environment. 4. `pip` downloads and installs the attacker-controlled package because no version or hash verification is required. 5. Malicious installation hooks or imported package code execute with the privileges of the user running `pip`. ### Impact Assessment Successful exploitation could execute arbitrary code under the installing user's account. Depending on that account's privileges, the attacker could access local files, environment variables, broker credentials, source code, and network resources available to the user. The issue does not directly provide privilege escalation beyond the privileges used during installation. The affected scope is the environment or host in which the dependencies are installe ...[truncated 6 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `pycryptodome` and `websocket-client` unless the implementation genuinely requires them. 2. Remove the unused `requests` import and dependency if no network integration is implemented. 3. Declare dependencies in a reviewed requirements or lock file with exact versions. 4. Use package hashes, for example through `pip install --require-hashes -r requirements.txt`. 5. Generate the lock file from a trusted package index and review transitive dependencies. 6. Integrate dependency vulnerability and provenance scanning into release procedures. 7. Avoid instructing users to install mutable dependency versions directly from documentation. ]]>

other

Error

• Location: quant_trading.py:69
• Finding: Live Trading Functionality Is Misrepresented by a Mock Implementation<![CDATA[ ## Vulnerability Details **File Location**: `quant_trading.py`, lines 69-90 **Vulnerability Type**: Deceptive financial functionality **Risk Level**: High ### Vulnerable Code The login operation creates a local token and fabricated account data without authenticating with a broker: ```python def login(self) -> Dict: """Login to broker""" # In production, would call actual broker API # This is a mock implementation self._token = f"token_{int(time.time())}" self.account_info = { 'account_id': self.account, 'account_name': 'Test Account', 'total_assets': 1000000.0, 'available': 800000.0, 'market_value': 200000.0, 'margin': 0, 'status': 'normal' } print(f"Logged in to {self.config['name']}") return {'success': True, 'token': self._token} ``` Order placement also marks an order as filled only in local memory: ```python self.orders.append(order) # Simulate order fill (in production, would wait for async callback) self._simulate_fill(order_id) return order ``` ```python def _simulate_fill(self, order_id: str): """Simulate order fill""" # In production, would use async callbacks for order in self.orders: if order['order_id'] == order_id: order['status'] = 'filled' order['filled'] = order['volume'] break ``` This conflicts with claims in `SKILL.md` that the package provides full broker APIs, real-time market data, order lifecycle management, scheduled execution, and automated risk controls. ### Technical Analysis The package behaves as an in-memory trading simulator rather than a live broker integration: - `login()` accepts an account and password but does not authenticate with a broker. - A predictable local token is generated from the current Unix timestamp. - Account balances and status values are hard-coded. - Market prices, volumes, and order books are generated locally. - Orders are immediately cha ...[truncated 2367 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Clearly identify the package as a simulation-only library in its name, metadata, documentation, examples, and runtime output. 2. Rename `TradingAPI` to an explicitly simulated interface such as `PaperTradingAPI` until real broker integration exists. 3. Reject or avoid requesting production broker passwords in simulation mode. 4. Add a prominent runtime banner and a machine-readable mode field indicating that all results are simulated. 5. Use distinct simulated order identifiers and statuses that cannot be confused with broker confirmations. 6. Remove unsupported claims concerning full broker integration, real-time data, scheduled execution, and active stop-loss or take-profit controls. 7. If live trading is implemented, use documented broker endpoints, secure authentication, TLS verification, request timeouts, response validation, and broker-issued order identifiers. 8. Do not mark orders as filled until a cryptographically and operationally trusted broker response or authenticated execution callback confirms the fill. 9. Persist and reconcile order state against the broker's authoritative records. 10. Add integration tests proving that advertised broker operations reach approved endpoints and correctly handle rejection, partial fill, timeout, and reconciliation scenarios. 11. Require an explicit environment and user confirmation before enabling live order placement. 12. Implement risk limits, symbol and quantity validation, idempotency protection, and immutable security audit logging before production use. ]]>

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (8)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: The documentation claims real broker integration, real-time data, and live order execution, but the analyzed behavior indicates mock or synthetic implementations instead of actual authenticated broker connectivity. In a financial-trading context, this is dangerous because users may make trading, risk, or deployment decisions based on false assumptions about execution, account state, and market data, potentially causing direct financial loss or unsafe automation.

Missing User Warnings

High

• Confidence: 94% confidence
• Finding: The strategy code can place buy and sell orders automatically during runtime without any confirmation, approval gate, risk limit, or explicit dry-run safeguard. In a trading skill, this is especially dangerous because erroneous strategy logic, bad data, or misuse can trigger immediate financial transactions and losses.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 86% confidence
• Finding: The skill documents capabilities that inherently require network access and likely credentials handling, but it does not declare any explicit tool scope or permissions boundary. In an agent ecosystem, missing scope declarations can cause reviewers and users to underestimate what the skill may access, reducing transparency and increasing the chance of unsafe execution with network or environment data exposure.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill describes placing buy/sell orders and managing orders without an explicit warning that such actions may be irreversible and can affect real assets. In a trading context, omission of this warning increases the chance that users treat examples as safe defaults and trigger unintended financial transactions or losses.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The automated strategy, scheduled order, stop loss, and take profit sections encourage unattended execution without clearly warning that automation can trade continuously or at specific times without further review. In a financial system, unattended execution can amplify mistakes, strategy bugs, stale data issues, or misconfiguration into repeated asset-impacting actions.

Natural-Language Policy Violations

Medium

• Confidence: 86% confidence
• Finding: The module description and class docstrings frame the skill as specifically for Chinese brokers, and the implementation hardcodes Chinese broker names, A-share trading hours, and Chinese stock labels. There is no natural-language indication that users can choose another locale or that the locale restriction is intentionally documented as a region-specific tool.

Intent-Code Divergence

Medium

• Confidence: 94% confidence
• Finding: The code claims to be a mock implementation, but the constructor still ingests real broker credentials from environment variables. This can mislead users into providing production secrets to code they may assume is non-sensitive test code, increasing the risk of accidental credential exposure, misuse, or later extension into real networked behavior.

Description-Behavior Mismatch

Low

• Confidence: 88% confidence
• Finding: The manifest explicitly scopes broker support to 华泰, 银河, 广发, and 中信建投. The BROKERS table additionally declares 'tonghuashun' with a Tushare API endpoint, extending beyond the described broker set and mixing a market-data provider into broker integration scope.

Static analysis

No suspicious patterns detected.