CyptoDataVault

• Outcome: Review
• Latest audit: Sep 16, 2026 · 6:21 AM UTC
• Version: 1.0.0

Overview

This Web3 data skill matches its advertised purpose, but it loads core code from outside the reviewed package and uses mutable dependency installation, so users should review it before installing.

Install only in an isolated environment and review the surrounding repository layout, because this package imports core implementation code that is not present in the reviewed artifact. Treat wallet addresses and API keys as sensitive, and prefer a pinned release or lockfile before using it with real credentials.

A.I.G

Vulnerability Patterns

• Tool Hijacking and Spoofing: Modifies or replaces tools so legitimate-looking calls execute attacker logic
• 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

Findings (2)

T07 · Tool Hijacking and Spoofing

Warning

• Location: __init__.py:9

Finding

Unreviewed Parent-Level Modules Can Hijack Skill Imports

Content

View full analysis

Vulnerability Details

File Location: __init__.py:9-14; tools/__init__.py:8-12
Vulnerability Type: Python import-path manipulation and tool implementation spoofing
Risk Level: Medium

Vulnerable Code

__init__.py:9-14:

python

# DataVault - 使用相对导入定位核心 app
# DataVault/skill/__init__.py -> DataVault/app/
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))

from app.data import get_data_service
from app.onchain.service import OnChainService
from app.external.defillama import get_defillama_client

tools/__init__.py:8-12:

python

# DataVault - 使用相对导入
# DataVault/skill/tools/__init__.py -> DataVault/
sys.path.insert(0, str(Path(__file__).resolve().parent.parent.parent))

from skill import get_skill, call_tool, get_all_tools

Technical Analysis

The Skill prepends directories outside its package boundary to Python's global module search path. Entries inserted at index zero take precedence over normal installed-package locations.

The app implementation imported by __init__.py is absent from the audited artifact. The local package therefore does not contain the implementations behind its advertised market-data, on-chain, and DeFi tools. Its effective behavior is determined by whichever matching app modules are present in the parent directory at runtime.

The tools adapter similarly imports the generic top-level module name skill after placing another parent directory first in the search path. This can resolve to code other than the reviewed package when the runtime directory structure differs from the expected repository layout.

Because Python executes module-level code during imports, resolving either import to attacker-controlled code results in immediate code execution. This is a conditional local hijacking vulnerability: exploitation requires an attacker or another compromised component to control a matching module in one of the inserted directories.

...[truncated 1781 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove both sys.path.insert(...) calls.

2. Package all required implementation modules inside the distributed Skill artifact.

3. Use explicit package-relative imports, for example:

   python

   from .app.data import get_data_service
   from .app.onchain.service import OnChainService
   from .app.external.defillama import get_defillama_client
   

4. In tools/__init__.py, use a relative import tied to the reviewed package rather than the generic top-level name skill.

5. Define a proper Python package and installation manifest so imports do not depend on the current working directory or repository layout.

6. Fail closed with a clear error when packaged implementation modules are unavailable.

7. Add tests that install the built artifact into an isolated environment and verify the resolved module paths using each module's __file__.

8. Avoid all process-wide import-path changes in library initialization code.

T08 · Insecure Dependencies

Warning

• Location: requirements.txt:4

Finding

Mutable and Unverified Dependencies Are Installed During Setup and Testing

Content

View full analysis

Vulnerability Details

File Location: requirements.txt:4-8; scripts/setup.sh:24-26; scripts/test.sh:30-32; README_OPENCLAW.md:17-25
Vulnerability Type: Unpinned dependency installation and mutable source retrieval
Risk Level: Medium

Vulnerable Code

requirements.txt:4-8:

text

requests>=2.31.0
pyyaml>=6.0

# Data (CCXT for exchange data)
ccxt>=4.3.0

scripts/setup.sh:24-26:

bash

# 安装依赖
echo "Installing dependencies..."
pip install -r requirements.txt

scripts/test.sh:30-32:

bash

# 安装依赖
echo -e "\n${GREEN}[1/4]${NC} Installing dependencies..."
pip install -q pyyaml requests ccxt 2>/dev/null || true

README_OPENCLAW.md:17-25:

bash

# 1. 克隆项目
git clone https://github.com/wangshuniguang/DataVault.git

# 2. 进入目录
cd DataVault

# 3. 安装依赖
pip install -r requirements.txt

Technical Analysis

The dependency manifest specifies only minimum versions and provides no upper bounds, exact pins, lockfile, package hashes, or repository index restrictions. A future invocation can therefore install package versions that were not present when the Skill was audited.

The test script is more permissive: it independently installs the latest resolver-selected versions of pyyaml, requests, and ccxt instead of using the dependency manifest. It suppresses error output and ignores installation failures with || true, making the resulting environment difficult to verify.

The manual installation instructions clone the current state of a mutable Git branch and then install its dependency manifest. No release tag, commit identifier, signature, or checksum is verified.

Python packages can execute code during build and installation, and imported dependencies execute code at runtime. Consequently, compromise of an upstream package, package index, repository, or future dependency release could turn the documented installation process into arbitrary ...[truncated 1789 chars]

Remediation

View remediation

Remediation Suggestions

1. Pin every production and testing dependency to an exact, reviewed version.
2. Generate a lockfile containing cryptographic hashes and require hash verification during installation, such as with pip-compile --generate-hashes and pip install --require-hashes.
3. Configure an explicit trusted package index and prevent dependency resolution from unintended public or extra indexes.
4. Add upper bounds where exact lockfile installation is not possible.
5. Remove dependency installation from scripts/test.sh; tests should run in a pre-provisioned, locked environment.
6. If test-time installation remains necessary, install exclusively from the same reviewed lockfile and do not suppress failures.
7. Remove 2>/dev/null || true so dependency failures stop the test run and remain visible.
8. Pin manual Git installation instructions to a reviewed commit or signed release tag and document checksum or signature verification.
9. Build and publish immutable artifacts from a controlled CI pipeline, and test the exact artifact users install.
10. Add automated dependency vulnerability, provenance, and integrity checks to release workflows.

SkillSpector

Vulnerability Patterns

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

Findings (23)

Credential Access

High

• Category: Privilege Escalation
• Confidence: 60% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · scripts/setup.sh (reported line 29)May include surrounding context.

sh

pip install -r requirements.txt

# 创建配置
if [ ! -f ".env" ]; then
    echo "Creating .env from template..."
    cat > .env << 'EOF'
# DataVault Configuration

Credential Access

High

• Category: Privilege Escalation
• Confidence: 60% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · README_OPENCLAW.md (reported line 115)May include surrounding context.

md

# 创建配置
if [ ! -f ".env" ]; then
    echo "Creating .env from template..."
    cat > .env << 'EOF'
# DataVault Configuration
DATAVAULT_API_KEY=your_api_key_here

Credential Access

High

• Category: Privilege Escalation
• Confidence: 60% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · SKILL.md (reported line 199)May include surrounding context.

md

# 创建配置
if [ ! -f ".env" ]; then
    echo "Creating .env from template..."
    cat > .env << 'EOF'
# DataVault Configuration
DATAVAULT_API_KEY=your_api_key_here

Credential Access

High

• Category: Privilege Escalation
• Confidence: 60% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · scripts/setup.sh (reported line 30)May include surrounding context.

sh

# 创建配置
if [ ! -f ".env" ]; then
    echo "Creating .env from template..."
    cat > .env << 'EOF'
# DataVault Configuration
DATAVAULT_API_KEY=your_api_key_here

Credential Access

High

• Category: Privilege Escalation
• Confidence: 60% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · scripts/setup.sh (reported line 31)May include surrounding context.

sh

# 创建配置
if [ ! -f ".env" ]; then
    echo "Creating .env from template..."
    cat > .env << 'EOF'
# DataVault Configuration
DATAVAULT_API_KEY=your_api_key_here

Credential Access

High

• Category: Privilege Escalation
• Confidence: 60% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · scripts/setup.sh (reported line 43)May include surrounding context.

sh

# 创建配置
if [ ! -f ".env" ]; then
    echo "Creating .env from template..."
    cat > .env << 'EOF'
# DataVault Configuration
DATAVAULT_API_KEY=your_api_key_here

Credential Access

High

• Category: Privilege Escalation
• Confidence: 60% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · scripts/setup.sh (reported line 61)May include surrounding context.

sh

# 创建配置
if [ ! -f ".env" ]; then
    echo "Creating .env from template..."
    cat > .env << 'EOF'
# DataVault Configuration
DATAVAULT_API_KEY=your_api_key_here

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

This markdown file is written entirely in Chinese, including headings, usage examples, and setup guidance, with no indication that users can choose another language or that the skill is intended only for a Chinese-speaking or region-specific audience. Under the policy rule for language or locale constraints, this is a natural-language policy issue because it imposes a specific language without user opt-in.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

This shell script contains user-facing comments and status text in Chinese, such as the title and section labels, without any indication that the skill is region-specific or that users can opt into another language. That can violate language/locale policy requirements for skills that should not force a specific language by default.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

The skill description is written entirely in Chinese at L05, and additional user-facing manifest fields also use Chinese. For a general-purpose skill manifest, this can violate language/locale policy when no user choice or opt-in is provided.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 89% confidence

Finding

The changelog and feature strings at L36 and L52-L55 are user-visible natural-language content in Chinese, but the manifest does not state that the skill is intended only for Chinese-speaking users or provide an alternative locale. This creates a language-policy concern for broadly distributed skills.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 76% confidence

Finding

The heading includes Chinese text in an otherwise English skill description, but the document does not explain a locale-specific purpose or offer a language preference choice. Under SQP-3, natural-language locale constraints or language forcing can be a policy issue when not documented or opt-in.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low

• Category: Not specified by scanner
• Confidence: 85% confidence

Finding

The markdown documents tools for retrieving an Ethereum address balance and transaction history, which can expose wallet activity and financial information, but it does not warn users about the privacy implications of querying wallet addresses. For markdown files, SQP-2 applies when descriptions omit warnings about behaviors that could affect user privacy.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

This Python file includes prominent natural-language descriptions in Chinese, such as the top-level module description, without indicating that other languages are supported. Under the stated policy, forcing a specific language or locale without user opt-in is a natural-language policy concern.

Content

No source excerpt is available for this finding.

Unpinned Dependencies

Low

• Category: Supply Chain
• Confidence: 92% confidence

Finding

The dependency on requests is specified with a lower bound only, which makes builds non-reproducible and can result in installation of different versions over time. This increases supply-chain risk and makes it difficult to verify whether a deployed version includes fixes for known security issues or accidentally pulls in a vulnerable release through environment-specific resolution.

Content

Scanner excerpt · requirements.txt (reported line 4)May include surrounding context.

text

# datavault-skill - Requirements

# Core
requests>=2.31.0
pyyaml>=6.0

# Data (CCXT for exchange data)

Unverifiable Dependency: requests has 16 known advisory(ies) (CVE-2014-1830 (Exposure of Sensitive Information to an Unauthorized Actor in Requests); CVE-2024-47081 (Requests vulnerable to .netrc credentials leak via malicious URLs); CVE-2024-35195 (Requests `Session` object does not verify requests after making first request wi) +13 more), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low

• Category: Supply Chain
• Confidence: 90% confidence

Finding

Requests has multiple known advisories, and because the manifest does not pin an exact version, there is no reliable way to determine whether an installed environment is affected. The danger here is not that requirements.txt proves exploitation, but that version ambiguity can permit deployment of a vulnerable requests release and undermine patch assurance.

Content

No source excerpt is available for this finding.

Unpinned Dependencies

Low

• Category: Supply Chain
• Confidence: 95% confidence

Finding

PyYAML is declared with an unpinned minimum version, which creates uncertainty about the exact package version installed and weakens reproducibility. This is more concerning than many libraries because PyYAML has a history of security issues around unsafe parsing and deserialization, so loose versioning complicates assurance that only safe, patched releases are used.

Content

Scanner excerpt · requirements.txt (reported line 5)May include surrounding context.

text

# Core
requests>=2.31.0
pyyaml>=6.0

# Data (CCXT for exchange data)
ccxt>=4.3.0

Unverifiable Dependency: pyyaml has 8 known advisory(ies) (CVE-2019-20477 (Deserialization of Untrusted Data in PyYAML); CVE-2020-1747 (Improper Input Validation in PyYAML); CVE-2020-14343 (Improper Input Validation in PyYAML) +5 more), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low

• Category: Supply Chain
• Confidence: 96% confidence

Finding

PyYAML has a significant history of vulnerabilities, including unsafe deserialization risks, and the unpinned dependency prevents verification that only a patched version will be installed. In a data-oriented skill, configuration or data ingestion paths may plausibly involve YAML, which makes this ambiguity more dangerous than a generic library with fewer security-relevant parsing behaviors.

Content

No source excerpt is available for this finding.

Unpinned Dependencies

Low

• Category: Supply Chain
• Confidence: 87% confidence

Finding

The ccxt dependency is also unpinned, so installation may vary across environments and over time. While this file alone does not show direct exploitation, unpinned third-party packages increase supply-chain and stability risk by allowing unreviewed upstream changes to enter the build unexpectedly.

Content

Scanner excerpt · requirements.txt (reported line 8)May include surrounding context.

text

pyyaml>=6.0

# Data (CCXT for exchange data)
ccxt>=4.3.0

# Caching (Optional)
# redis>=5.0.0  # For production

Unpinned Dependencies

Low

• Category: Supply Chain
• Confidence: 50% confidence

Finding

Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.

Content

Scanner excerpt · requirements.txt (reported line 14)May include surrounding context.

text

# redis>=5.0.0  # For production

# Testing
pytest>=7.4.0

Unverifiable Dependency: pytest has 2 known advisory(ies) (CVE-2025-71176 (pytest has vulnerable tmpdir handling); CVE-2025-71176 (pytest has vulnerable tmpdir handling)), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low

• Category: Supply Chain
• Confidence: 40% confidence

Finding

Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

Line L02 contains a Chinese description comment while the rest of the script's user-facing messages are in English. This imposes language assumptions without documenting a user-selectable locale or clearly justifying the mixed-language behavior.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

The module docstring and comments contain Chinese-language text such as "全球领先的 Web3 Data Value 平台" and "使用相对导入". Because this file provides human-readable instructions/description without any user opt-in or justification for a fixed locale, it may conflict with language-choice policy expectations.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.