Broadcast Signed Transaction

• Outcome: Review
• Latest audit: Sep 11, 2026 · 1:09 AM UTC
• Version: 1.0.0

Overview

The skill performs its stated transaction-broadcasting job, but it handles sensitive OKX credentials and irreversible blockchain broadcasts with some under-scoped and under-documented behavior.

Review this before installing if you will use real OKX credentials or broadcast valuable transactions. Prefer environment variables or a secret manager over command-line credential flags, use narrowly scoped OKX Web3 API keys, confirm the signed transaction and chain before broadcast because it cannot be undone, and install dependencies in a pinned virtual environment.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• 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

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/broadcast_signed_tx.py:321
• Finding: OKX Credentials Exposed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/broadcast_signed_tx.py`, lines 321-326 **Vulnerability Type**: Sensitive credential exposure through process arguments **Risk Level**: Medium ### Vulnerable Code ```python parser.add_argument("--api-key", default="", help="OKX API Key（默认读 OKX_ACCESS_KEY 环境变量）") parser.add_argument("--secret-key", default="", dest="secret_key", help="OKX Secret Key（默认读 OKX_SECRET_KEY 环境变量）") parser.add_argument("--passphrase", default="", help="OKX Passphrase（默认读 OKX_PASSPHRASE 环境变量）") ``` ### Technical Analysis The command-line interface permits the OKX API key, secret key, and passphrase to be supplied directly as process arguments. Command-line arguments are not an appropriate secret-transport mechanism because they can be: - Recorded in shell history. - Captured by terminal logging or command telemetry. - Exposed through process inspection facilities while the script is running. - Retained in automation logs, job definitions, diagnostic reports, or monitoring systems. The script already supports loading the same credentials from specifically named environment variables, so exposing additional secret-bearing command-line options is not necessary for its declared transaction-broadcasting functionality. The API secret is used locally to generate an HMAC-SHA256 signature and is not itself sent to the OKX endpoint. The vulnerability concerns local disclosure caused by the CLI interface, not the legitimate authenticated HTTPS request. ### Attack Path 1. A user invokes the Skill with `--api-key`, `--secret-key`, or `--passphrase`. 2. The plaintext credential becomes part of the command line. 3. The command is retained in shell history, automation logs, process metadata, or terminal telemetry. 4. A local user, support operator, monitoring service, or compromised process with access to that data retrieves the credential. 5. The exposed credential is r ...[truncated 846 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the `--api-key`, `--secret-key`, and `--passphrase` command-line options. 2. Load credentials from protected environment variables, an operating-system credential store, or a configuration file with restrictive filesystem permissions. 3. If interactive credential entry is required, use `getpass.getpass()` so secrets are not echoed. 4. Ensure application logs and exception messages never include credentials or complete authentication headers. 5. Recommend narrowly scoped, short-lived API credentials with only the permissions required to broadcast transactions. 6. Apply OKX-supported IP restrictions or equivalent account controls where available. 7. If command-line compatibility must temporarily be retained, display a prominent deprecation warning and document that command-line secret submission is unsafe. ]]>

T08 · Insecure Dependencies

Note

• Location: SKILL.md:265
• Finding: Unpinned Third-Party Dependency Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 265-268 **Vulnerability Type**: Mutable and unverified dependency installation **Risk Level**: Low ### Vulnerable Code ```bash # 仅依赖 requests，无需 web3 pip3 install requests ``` ### Technical Analysis The installation instructions retrieve `requests` without a version constraint, lockfile, integrity hash, or isolated environment. Consequently, the package and its transitive dependencies are resolved from mutable package-index state at installation time rather than from artifacts reviewed together with this Skill. This does not demonstrate that the legitimate `requests` package is malicious. The risk arises because future releases, compromised publishing accounts, altered package-index configuration, or unexpected dependency resolution can cause users to install code different from the code considered during the audit. Python package installation may execute package build logic, and imported dependencies execute with the privileges of the user running the Skill. The absence of version and hash controls therefore creates avoidable supply-chain exposure. ### Attack Path 1. A user follows the documented `pip3 install requests` command. 2. `pip` resolves the latest compatible package and transitive dependencies using the user's configured package indexes. 3. A compromised release, malicious index substitution, or unexpected future artifact is selected. 4. Installation-time build logic or runtime import code executes on the user's system. 5. The dependency gains the privileges of the account running installation or executing the transaction-broadcast script. This attack path depends on compromise or manipulation of the dependency distribution channel; no malicious package or unsafe custom index is embedded in the audited project. ### Impact Assessment A malicious dependency could execute arbitrary Python code with the privileges of the installing or invoking user. Depending on those priv ...[truncated 360 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Create a reviewed dependency file with an exact `requests` version and all required transitive dependencies pinned. 2. Record cryptographic hashes and install with: ```bash python3 -m pip install --require-hashes -r requirements.txt ``` 3. Generate and review the lock data using a reproducible dependency-management tool. 4. Install dependencies in a dedicated virtual environment rather than the global Python environment. 5. Configure trusted package indexes explicitly and avoid unreviewed mirrors. 6. Use automated dependency monitoring to identify vulnerable or compromised releases and update pins through a reviewed process. 7. Document the supported Python version to reduce inconsistent dependency resolution across environments. ]]>

SkillSpector

Vulnerability Patterns

• Taint Tracking: Direct Taint Flow, Variable-Mediated Taint Flow, Credential Exfiltration Chain
• 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 (4)

Tainted flow: 'headers' from os.environ.get (line 184, credential/environment) → requests.post (network output)

Critical

• Category: Data Flow

Content

# 发起请求
    try:
        resp = requests.post(
            OKX_BASE_URL + BROADCAST_PATH,
            headers=headers,
            data=body_str.encode("utf-8"),

• Confidence: 90% confidence
• Finding: Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The declared purpose says the skill simply broadcasts signed hex transactions without private keys, but the documented behavior also relies on undeclared external OKX credentials, adds MEV-protection behavior, and references chains like Solana that do not match the stated EVM/hex transaction model. This mismatch is dangerous because operators and agents may trust a narrower safety profile than the skill actually has, leading to misuse, accidental credential handling, incorrect transaction assumptions, or broadcasting on unintended chains/providers.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 92% confidence
• Finding: The skill declares no explicit tool scope or permissions despite clearly requiring environment variable access and outbound network access to OKX APIs. This creates an authorization transparency gap: an agent or user may invoke the skill without understanding it can read local secrets and send data externally, increasing the risk of unintended credential exposure or overbroad execution in permissive runtimes.

Description-Behavior Mismatch

Low

• Confidence: 95% confidence
• Finding: The manifest describes the skill as broadcasting signed hex transactions, which implies EVM-style hex payloads. However, the code explicitly adds Solana support in CHAIN_INFO and validation logic treats Solana as a non-EVM chain whose signed transaction does not start with 0x, expanding behavior beyond the stated hex-only scope.

Static analysis

No suspicious patterns detected.