Xian SDK

• Outcome: Review
• Latest audit: Sep 10, 2026 · 11:16 AM UTC
• Version: 0.1.0

Overview

This skill is a coherent Xian blockchain SDK guide, but it under-warns users around private keys and irreversible on-chain actions.

Review this skill carefully before installing or using it. Treat all private keys and mnemonics as secrets, do not copy the shown private key, do not print secrets into logs or transcripts, pin dependencies in a dedicated environment, and run transaction or deployment examples only against a local or test network until you have explicitly confirmed the recipient, amount, contract, and fees.

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)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:11
• Finding: Unpinned Third-Party SDK Installation## Vulnerability Details **File Location**: `SKILL.md`, lines 11–16 **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Medium **Vulnerable Code Snippet**: ```bash pip install xian-py # With Ethereum wallet support pip install "xian-py[eth]" ``` ### Technical Analysis The installation instructions retrieve the latest available version of `xian-py` and its optional Ethereum dependencies from the active Python package index. Neither an exact version nor package hashes are specified. Consequently, the code installed by these commands may differ from the version originally reviewed. A compromised maintainer account, malicious replacement release, dependency compromise, or unexpected upstream change could introduce arbitrary code into the installation. Python packages can execute code during installation and later when imported or used. The package name is consistent with the declared Xian SDK, and the audited files contain no evidence that it is currently malicious. The vulnerability is the absence of controls that ensure users receive a known, reviewed artifact. ### Attack Path 1. An attacker compromises the package publisher, an upstream dependency, or the configured package index. 2. The attacker publishes a malicious version under the expected package name. 3. A user follows the documented unpinned `pip install` command. 4. Pip resolves and installs the attacker-controlled release. 5. Malicious code executes during installation or when the SDK is imported. 6. The code accesses credentials, wallet keys, files, network resources, or other assets available to the installing user. ### Impact Assessment Successful exploitation can execute arbitrary code with the privileges of the user running pip or the application. Because the documented SDK handles blockchain wallets and transaction signing, compromised dependency code could access private keys, alter recipient addresses, forge ...[truncated 159 chars]
• Remediation: ## Remediation Suggestions - Pin the SDK and all transitive dependencies to reviewed, exact versions. - Generate a lock file and require cryptographic hashes, such as through `pip install --require-hashes -r requirements.txt`. - Document the expected official package index and reject untrusted extra indexes. - Verify package provenance, release signatures, and hashes before updating pinned versions. - Review dependency changes before upgrading. - Recommend installation inside a dedicated virtual environment or restricted container. - Avoid running pip with root or administrator privileges.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:46
• Finding: Public Hard-Coded Wallet Private Key in Executable Example## Vulnerability Details **File Location**: `SKILL.md`, line 46 **Vulnerability Type**: Hard-coded cryptographic secret **Risk Level**: Medium **Vulnerable Code Snippet**: ```python wallet = Wallet('ed30796abc4ab47a97bfb37359f50a9c362c7b304a4b4ad1b3f5369ecb6f7fd8') ``` ### Technical Analysis The documentation embeds a syntactically plausible wallet private key in directly executable Python code. Because the key is publicly documented, every user and attacker can derive or access the same wallet identity. Users commonly copy documentation examples into applications or test environments. If this example key is reused to receive assets, sign transactions, or deploy contracts, those assets and privileges are immediately available to anyone who has read the documentation. The surrounding guidance also demonstrates printing wallet private keys and mnemonic phrases, which increases the likelihood that sensitive wallet material will be retained in terminal history, logs, screenshots, or agent transcripts. This finding does not establish that the displayed key currently controls funded assets. The vulnerability arises from presenting a public, reusable private key as a valid wallet-construction example. ### Attack Path 1. A user copies the example into an application, script, or test environment without replacing the embedded key. 2. The user funds the resulting wallet, grants it contract privileges, or uses it as a transaction signer. 3. An attacker copies the same private key from the public documentation. 4. The attacker imports the key into a compatible wallet. 5. The attacker signs valid transactions as the affected wallet. 6. The attacker transfers funds, invokes privileged contract functions, or otherwise impersonates the wallet owner. ### Impact Assessment Exploitation grants full signing authority for the wallet derived from the exposed private key. The attacker can exercise every blockchain permission assigned t ...[truncated 261 chars]
• Remediation: ## Remediation Suggestions - Replace the value with an unmistakably invalid placeholder, such as `YOUR_PRIVATE_KEY_FROM_SECURE_STORAGE`. - Ensure the example cannot run until the user supplies a securely generated key. - Load production keys from a dedicated secrets manager, hardware wallet, or protected environment injection mechanism. - Never commit private keys or mnemonic phrases to source control. - Remove examples that print private keys or mnemonic phrases to standard output. - Warn users explicitly that example credentials must never receive funds or receive contract privileges. - Add secret-scanning checks to documentation and source-control workflows. - If the displayed key has ever controlled assets or privileges, permanently retire it and migrate those assets and permissions to a newly generated wallet.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The wallet examples include handling and printing of private keys and mnemonic material without strong warnings that these secrets must never be exposed, logged, or embedded in code. This normalizes unsafe secret-handling practices and could lead users to leak credentials that enable theft of blockchain assets or account takeover.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The examples invoke real blockchain operations such as token transfers, contract calls, and contract deployment against a live node URL without any warning that these actions may spend funds, consume fees, or be irreversible. In a developer skill, users often copy-paste examples directly, so omission of safety guidance materially increases the risk of accidental fund loss or unintended on-chain actions.

Context-Inappropriate Capability

Medium

• Confidence: 95% confidence
• Finding: The upgradeable example exposes a dangerous pattern: user-influenced dynamic module import and arbitrary function dispatch via `importlib.import_module()` and `getattr()` without any allowlist, interface validation, or safety boundary. In a smart-contract reference document, this can normalize an unsafe design that enables execution of unintended code paths or malicious implementations if an owner key is compromised or the implementation target is set to an attacker-controlled module.

Static analysis

No suspicious patterns detected.