Back to skill

Security audit

区块链数据服务

Security checks for vulnerabilities and agentic risk

Overview

This skill appears to be a read-only blockchain data client, but it automatically stores a third-party API key in a local .env file and has enough stale or mismatched metadata to warrant review before installation.

Review this carefully before installing. Only use it if you trust the xiaobenyang.com API service, are comfortable sending wallet addresses, token IDs, transaction hashes, and your XBY API key to that service, and accept that the key will be written to a local .env file unless the skill is changed.

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
Findings (21)

Lp3

Medium
Category
MCP Least Privilege
Confidence
92% confidence
Finding
The skill declares itself as a read-only blockchain data service, but the documented workflow clearly involves environment access, local file writes, and outbound network calls without corresponding permission disclosure. This creates a transparency and least-privilege problem: users and hosting platforms may not realize the skill can persist secrets and communicate externally.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The skill description says it is a read-only Vitruveo MCP server, but the content instructs the agent to collect and store API keys, modify configuration, and use an outbound API client for broader EVM queries. This mismatch undermines user trust and can conceal sensitive behaviors, especially credential handling and third-party data transmission, behind an apparently narrow blockchain-read-only description.

Description-Behavior Mismatch

Medium
Confidence
94% confidence
Finding
A skill marketed as read-only blockchain access should not silently expand scope into local secret persistence without clear disclosure and consent. Persisting a user-supplied API key to local configuration increases the risk of credential leakage through filesystem exposure, logs, backups, or later misuse by other components.

Intent-Code Divergence

High
Confidence
90% confidence
Finding
References to unrelated gaokao/xiaobenyang components and contradictory project structure strongly suggest the skill was copied, repurposed, or inconsistently assembled. That inconsistency increases supply-chain and prompt-injection risk because users cannot reliably determine what service they are actually invoking, where data is sent, or which code paths are active.

Description-Behavior Mismatch

Medium
Confidence
92% confidence
Finding
This code is a generic outbound API wrapper that accepts arbitrary MCP identifiers, tool names, and parameters, while the skill is ներկայացted as a read-only Vitruveo blockchain data service. That mismatch expands the reachable behavior beyond the declared trust boundary, which can enable unintended remote actions or data access if higher layers expose these inputs.

Context-Inappropriate Capability

Medium
Confidence
96% confidence
Finding
The request headers directly embed caller-controlled tool_name and mcp_id and the body forwards arbitrary params to an upstream MCP API without local authorization checks. In an agent setting, this creates a broad remote tool invocation primitive that may be abused to reach unintended upstream functions, making it more dangerous than a narrowly scoped read-only blockchain client.

Description-Behavior Mismatch

High
Confidence
94% confidence
Finding
The module implements credential persistence and mutation helpers even though the declared skill purpose is read-only blockchain data access. While storing an API key is sometimes operationally necessary, silently writing it to a local .env file expands the secret exposure surface and is not clearly justified by the stated functionality.

Context-Inappropriate Capability

Medium
Confidence
91% confidence
Finding
The save_api_key_to_env function adds persistent local secret storage that is broader than what a read-only data retrieval skill typically needs. This increases the chance of accidental disclosure through local file access, backups, repository mistakes, or multi-user environments.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill instructs the agent to ask the user for an API key and save it, but gives no warning about how the credential will be stored, who can access it, or which external service will use it. This is dangerous because users may disclose sensitive secrets under the assumption they are used transiently, when in fact they may be written to disk or exposed to other tooling.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The code persists an API key to .env with no user-facing warning, consent flow, or disclosure that the credential will be written to disk. Secret storage without notice can violate user expectations and increases the likelihood of unintentional credential leakage from local files.

Missing User Warnings

Medium
Confidence
81% confidence
Finding
These wrappers forward user-supplied wallet addresses, ENS names, token addresses, NFT identifiers, and transaction hashes to a remote API via call_api without any visible notice, minimization, or consent controls in this file. In an agent context, this can leak sensitive user interest, holdings, and investigation targets to an external service, creating privacy and profiling risk even though the operations are read-only.

Credential Access

High
Category
Privilege Escalation
Content
default_year: int = 2025

    def model_post_init(self, __context):
        # 强制从 .env 文件读取 XBY_APIKEY
        env_path = Path(".env")
        if env_path.exists():
            content = env_path.read_text(encoding="utf-8")
Confidence
84% confidence
Finding
The code manually reads the .env file and extracts XBY_APIKEY outside the normal settings framework, creating custom secret-handling logic that is harder to audit and easier to misuse. In the context of a read-only service, this extra credential access behavior is unnecessary and increases secret exposure risk.

Credential Access

High
Category
Privilege Escalation
Content
def model_post_init(self, __context):
        # 强制从 .env 文件读取 XBY_APIKEY
        env_path = Path(".env")
        if env_path.exists():
            content = env_path.read_text(encoding="utf-8")
            for line in content.splitlines():
Confidence
84% confidence
Finding
Opening and reading the entire .env file to search for a credential increases exposure of locally stored secrets and bypasses safer, declarative configuration patterns. This is particularly questionable because the skill's advertised behavior does not suggest a need for custom credential-file inspection.

Credential Access

High
Category
Privilege Escalation
Content
def save_api_key_to_env(api_key: str) -> bool:
    """将API key保存到.env文件"""
    try:
        env_path = Path(".env")
        lines = []
        if env_path.exists():
            lines = env_path.read_text(encoding="utf-8").splitlines()
Confidence
92% confidence
Finding
The function is explicitly designed to save an API key into a .env file, turning a runtime credential into a persistent local secret. This broadens the attack surface through disk exposure, accidental commits, workstation compromise, and other local disclosure paths.

Credential Access

High
Category
Privilege Escalation
Content
def set_api_key(api_key: str) -> bool:
    """设置API key并持久化到.env"""
    if not api_key or not api_key.strip():
        return False
    api_key = api_key.strip()
Confidence
90% confidence
Finding
The helper wraps API-key setting with automatic persistence to .env, making disk storage the default behavior for a secret. In this skill context, that is more dangerous because the declared functionality is simple read-only access and does not justify expanded credential-management capability.

Unpinned Dependencies

Low
Category
Supply Chain
Content
requests>=2.31.0
pydantic>=2.7.0
pydantic-settings>=2.2.0
python-dotenv>=1.0.1
Confidence
95% confidence
Finding
The dependency is specified with a lower-bound range (`requests>=2.31.0`) rather than a fixed version, which makes builds non-reproducible and can pull in unexpected upstream releases over time. In a security-sensitive service, especially one exposed to agents, this increases supply-chain risk and complicates patch verification, even though it is not an exploit by itself.

Unpinned Dependencies

Low
Category
Supply Chain
Content
requests>=2.31.0
pydantic>=2.7.0
pydantic-settings>=2.2.0
python-dotenv>=1.0.1
Confidence
95% confidence
Finding
`pydantic>=2.7.0` is unpinned, so deployments may resolve to different versions at different times. That creates avoidable supply-chain uncertainty and can introduce breaking or vulnerable transitive code without an explicit review.

Unpinned Dependencies

Low
Category
Supply Chain
Content
requests>=2.31.0
pydantic>=2.7.0
pydantic-settings>=2.2.0
python-dotenv>=1.0.1
Confidence
95% confidence
Finding
`pydantic-settings>=2.2.0` allows any newer version, reducing reproducibility and increasing the chance of consuming an unsafe or incompatible release. This is a common dependency hygiene issue rather than evidence of malicious behavior.

Unpinned Dependencies

Low
Category
Supply Chain
Content
requests>=2.31.0
pydantic>=2.7.0
pydantic-settings>=2.2.0
python-dotenv>=1.0.1
Confidence
95% confidence
Finding
`python-dotenv>=1.0.1` is not pinned, which permits future installs to resolve unpredictably. While low severity on its own, this weakens supply-chain control and makes it harder to guarantee secure, repeatable environments.

Known Vulnerable Dependency: requests==2.31.0 — 5 advisory(ies): 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); CVE-2026-25645 (Requests has Insecure Temp File Reuse in its extract_zipped_paths() utility func) +2 more

Medium
Category
Supply Chain
Confidence
84% confidence
Finding
The requirements permit `requests` 2.31.0, and the static analysis identifies that version as having published advisories. Because the specifier is `>=2.31.0`, some installs may get a patched version, but environments can still resolve to or remain on the vulnerable release, making this a real dependency risk for any code that performs HTTP requests.

Known Vulnerable Dependency: python-dotenv==1.0.1 — 1 advisory(ies): CVE-2026-28684 (python-dotenv: Symlink following in set_key allows arbitrary file overwrite via )

Low
Category
Supply Chain
Confidence
73% confidence
Finding
The file allows `python-dotenv` 1.0.1, which is flagged by the scanner as vulnerable. Even if the skill is described as read-only blockchain access, using a vulnerable dotenv helper can still matter during configuration management or local tooling, though the practical risk depends on whether the affected function is used.

Static analysis

No suspicious patterns detected.