Back to skill

Security audit

Send to FMZ

Security checks for vulnerabilities and agentic risk

Overview

This skill is intended to send trading signals, but it uses broad live-trading authority with weak scoping and misleading security assumptions that users should review before installing.

Install only if you understand that this can send live trading commands to FMZ. Replace the hardcoded UUID with a private deployment secret, avoid broadcast node_id 0 unless intentionally needed, add explicit confirmation or dry-run behavior for buy/sell/close actions, and verify FMZ responses before treating a signal as accepted.

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

T09 · Insecure Skill Coding Practices

Error
Location
handler.py:5
Finding
Hardcoded Signal Verification Identifier## Vulnerability Details **File Location**: `handler.py`, line 5 **Vulnerability Type**: Hardcoded authentication or source-verification material **Risk Level**: High ### Vulnerable Code ```python MY_UUID = "530032201" ``` ### Technical Analysis The UUID used to identify or verify the source of FMZ trading signals is embedded directly in the distributed source code. The skill documentation describes this UUID as a security mechanism intended to prevent unauthorized signals. Because it is stored in plaintext, anyone with access to the project can recover and reuse it. The UUID does not provide meaningful source authentication after disclosure. If an FMZ robot trusts the value contained in the signal as proof of authorization, an attacker can construct forged messages that appear to originate from this skill. The implementation does not add a cryptographic signature, timestamp, nonce, or other replay protection. ### Attack Path 1. An attacker obtains a copy of the skill or otherwise reads `handler.py`. 2. The attacker extracts the hardcoded UUID `530032201`. 3. The attacker creates a request to the documented FMZ channel endpoint with a forged `cmd` object containing that UUID. 4. The attacker selects an arbitrary supported action, symbol, price, and reason. 5. If a receiving robot treats possession of the UUID as authorization, it accepts the forged signal as trusted. ### Impact Assessment An attacker may impersonate the expected signal source and submit unauthorized trading instructions to robots configured to trust the exposed UUID. Depending on the receiving robot's strategy and exchange permissions, this could influence buy, sell, close, or wait decisions and potentially cause financial loss. The code does not directly expose exchange credentials or independently place exchange orders. The final impact depends on how FMZ and the listening robots validate and execute incoming signals.
Remediation
## Remediation Suggestions - Remove the identifier from source control and rotate the exposed value. - Load deployment-specific credentials from an environment variable or managed secret store. - Fail securely when the required secret is absent rather than using a default value. - Use a cryptographic message authentication code or digital signature over the complete signal payload. - Include a timestamp and unique nonce in each signed message, and reject expired or replayed messages. - Restrict accepted requests at the FMZ receiver by account, robot, source, and permitted action where supported. - Add secret-scanning checks to the development and release pipelines.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
handler.py:26
Finding
Trading Signals Are Broadcast to All Robots## Vulnerability Details **File Location**: `handler.py`, lines 26-30 **Vulnerability Type**: Overbroad robot targeting and violation of least privilege **Risk Level**: High ### Vulnerable Code ```python payload = { "node_id": 0, # 0代表广播给所有机器人 "cmd": json.dumps(signal_data) } ``` ### Technical Analysis The payload fixes `node_id` to `0`, which the source comment identifies as broadcasting to every robot. This conflicts with the documented purpose of sending a signal to a specific robot instance and does not apply least-privilege targeting. Callers cannot select or constrain the destination robot. Consequently, every invocation uses the broadest destination scope available to the channel. The handler also lacks an authorization policy or confirmation step for state-changing actions such as `buy`, `sell`, or `close`. ### Attack Path 1. A caller invokes `handler` with a supported state-changing action. 2. The handler serializes the caller-controlled action, symbol, price, and reason. 3. It assigns `node_id` the broadcast value `0`. 4. The request is sent to the FMZ channel endpoint. 5. Every robot listening within the applicable broadcast scope can receive the command. 6. Robots configured to act on the signal may independently initiate trading behavior. ### Impact Assessment A single intended signal can reach multiple robots instead of one explicitly authorized target. This expands the scope of any mistake, compromised invocation, or forged signal and may cause duplicated or inconsistent trading activity across separate strategies or accounts. The handler itself does not demonstrate direct exchange-order execution. Actual financial impact depends on the number of listening robots, their exchange privileges, and whether they automatically act on received signals.
Remediation
## Remediation Suggestions - Replace the fixed broadcast value with an explicit, deployment-configured robot or node identifier. - Deny `node_id = 0` by default and permit broadcasting only through a separate, explicitly authorized workflow. - Validate the selected node against an allowlist belonging to the current deployment. - Require confirmation or policy approval before transmitting `buy`, `sell`, or `close` actions. - Apply per-robot authorization and action restrictions at the receiving side. - Record the destination, action, caller, request identifier, and validated response in an audit log. - Update the documentation so the stated targeting behavior precisely matches the implementation.

T09 · Insecure Skill Coding Practices

Warning
Location
handler.py:36
Finding
HTTP Error Responses Are Reported as Successful Signal Delivery## Vulnerability Details **File Location**: `handler.py`, lines 36-37 **Vulnerability Type**: Missing HTTP status and response validation **Risk Level**: Medium ### Vulnerable Code ```python resp = requests.post(url, json=payload, timeout=5) return f"信号发送成功: {action} {symbol}, 状态码: {resp.status_code}" ``` ### Technical Analysis The handler reports signal transmission as successful whenever `requests.post` returns an HTTP response. It does not call `raise_for_status()` or verify that the response body confirms acceptance. The `requests` library does not raise an exception merely because a server returns a `4xx` or `5xx` status. Therefore, authentication failures, rate limiting, malformed requests, and server errors all reach the unconditional success return path. A redirect or unexpected successful response may also be accepted without verifying that FMZ processed the signal. ### Attack Path 1. The handler submits a trading signal. 2. FMZ or an intermediary returns a rejection or server-error response without causing a network exception. 3. The handler skips status and response-body validation. 4. It returns a message claiming that the signal was sent successfully. 5. The calling agent or user proceeds under the false assumption that the target robot received and accepted the instruction. ### Impact Assessment This flaw does not directly grant additional privileges. It compromises the integrity and reliability of trading automation by creating a false execution state. Callers may fail to retry a rejected close instruction, issue conflicting follow-up actions, or make decisions based on a trade signal that was never accepted. In a trading environment, such state divergence can contribute to unmanaged positions and financial loss.
Remediation
## Remediation Suggestions - Call `resp.raise_for_status()` before reporting success. - Parse and validate the FMZ response body against the documented success schema. - Treat unexpected content types, redirects, malformed responses, and missing acknowledgement fields as failures. - Return a structured result containing a boolean success value, status code, request identifier, and sanitized error details. - Distinguish retryable failures, such as timeouts or rate limits, from permanent validation and authorization failures. - Implement bounded retries with exponential backoff only for idempotent or safely deduplicated requests. - Ensure receiving systems use unique request identifiers to prevent duplicate trading actions during retries.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (5)

Lp3

Medium
Category
MCP Least Privilege
Confidence
95% confidence
Finding
The skill performs network-capable, real-world trading actions but does not declare any explicit tool scope or permission boundaries. In an agent environment, this increases the chance of unintended or unauthorized outbound requests and trade execution because neither the user nor the runtime is clearly warned or constrained.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The skill is designed to send live trading signals to an external platform, but the description does not clearly warn that using it can trigger real financial actions. This creates a significant risk of accidental trade execution, especially in autonomous or semi-autonomous agent workflows where users may interpret the skill as informational rather than action-taking.

External Transmission

Medium
Category
Data Exfiltration
Content
# 发送请求
        # 注意:如果你的 OpenClaw 环境没有 requests 库,可能需要其他方式
        # 但标准 Python 环境通常支持
        resp = requests.post(url, json=payload, timeout=5)
        return f"信号发送成功: {action} {symbol}, 状态码: {resp.status_code}"
    except Exception as e:
        return f"信号发送失败: {str(e)}"
Confidence
80% 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 code sends action, symbol, price, reason, and UUID data to an external FMZ API via an HTTP POST request. While there are developer comments describing the request, there is no user-facing warning, confirmation, or visible disclosure that this data will be transmitted to an external service.

Natural-Language Policy Violations

Low
Confidence
80% confidence
Finding
The file's human-readable comments and docstring are written entirely in Chinese, including imperative setup guidance and function description, without indicating that another language is supported. This can constitute a language policy violation when a skill effectively requires a specific language without user opt-in or documented justification.

Static analysis

No suspicious patterns detected.