股票数据服务

• Outcome: Review
• Latest audit: Jul 9, 2026 · 5:21 AM UTC
• Version: 1.0.1

Overview

This stock-data skill routes requests and API keys through a third-party XiaoBenYang service while presenting itself as AKShare-based, and it stores the key in a local .env file.

Review carefully before installing. Only use this if you are comfortable giving a XiaoBenYang API key to the skill, storing it in a local .env file, and sending stock queries and optional token parameters to the XiaoBenYang remote API rather than a directly disclosed AKShare integration.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (21)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 94% confidence
• Finding: The skill documentation directs the agent to read configuration state, write an API key via `set_api_key()`, and call remote services, yet no explicit permissions or user-facing capability disclosure is declared. This is dangerous because the skill gains effective access to environment/configuration, local file persistence, and network operations without transparent scoping, increasing the chance of silent credential handling or unintended side effects.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: The skill claims to be an AKShare-based stock data MCP server, but the documented behavior routes through an unrelated XiaoBenYang remote API service and local API-key persistence. This mismatch is dangerous because users and orchestrators may trust the skill under false assumptions about data source, trust boundary, and where credentials are sent, enabling credential exfiltration or supply-chain style deception.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The document presents itself as a stock-data service, but the workflow and project structure reference a gaokao/school-search skill, indicating strong signs of repurposed or deceptive instructions. This context makes the mismatch more dangerous because it suggests the operator may be concealing the real toolchain or backend, undermining trust and creating opportunities for unauthorized data handling or misrouted requests.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The example tool invocation shows school-search parameters instead of stock-data parameters, which indicates the skill instructions were copied from another domain without proper validation. This is dangerous because it can cause the agent to invoke incorrect tools or pass user input into unintended functions, eroding safety guarantees and increasing the risk of data misuse.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The skill metadata claims the service is an AKShare-based Chinese stock data server, but this file actually forwards requests to an unrelated external '小笨羊MCP' API. That mismatch is dangerous because users and downstream systems may disclose market queries, parameters, and secrets under false assumptions about the data source and trust boundary, enabling covert data exfiltration or unauthorized third-party dependency use.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The configuration module materially contradicts the declared stock-data skill by using gaokao/XBY branding, a different env prefix, a hardcoded remote base URL, and a different API-key name. This kind of identity mismatch is dangerous because it can cause operators to supply secrets to the wrong service or route requests to an unintended backend, creating a supply-chain or credential-misdirection risk.

Intent-Code Divergence

High

• Confidence: 97% confidence
• Finding: The inline documentation and identifiers describe an unrelated gaokao/XBY skill despite the package being presented as a stock-data service. In security review, this mismatch is a red flag because it can conceal copied or repurposed code paths that send data or credentials to an unrelated service, making trust and auditability significantly worse.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The skill explicitly instructs the agent to ask the user for an API key and persist it locally via `scripts.config.set_api_key(api_key)` without any warning, consent flow, or storage safeguards. This is dangerous because users may disclose secrets expecting transient use, while the skill silently stores them on disk where they may be exposed to other components, logs, or future sessions.

Missing User Warnings

Medium

• Confidence: 85% confidence
• Finding: This code sends arbitrary tool parameters together with an API key to a remote upstream service, but there is no in-file mechanism for disclosure, consent, minimization, or redaction. In the context of an agent skill, parameters may contain user prompts, identifiers, or sensitive financial queries, so silent transmission to a third party expands privacy and supply-chain risk.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The code persists the provided API key directly into a local .env file without any consent prompt, warning, or secure-storage option. This is risky because .env files are often world-readable in developer environments, accidentally committed, or exposed through backups and logs, leading to credential disclosure.

Missing User Warnings

High

• Confidence: 88% confidence
• Finding: The function accepts an authentication token and forwards it to an external API via call_api, but this wrapper provides no validation, scoping, masking, or explicit disclosure of that sensitive transmission. In a skill context, users may supply tokens without understanding they are being relayed to third-party services, increasing the risk of credential exposure through logging, telemetry, or misuse by downstream components.

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: 94% confidence
• Finding: The code forcefully reads the .env file manually to extract XBY_APIKEY, bypassing the normal settings abstraction and intentionally pulling a secret from local plaintext storage. This increases the chance of mishandled credentials, inconsistent secret sources, and covert reuse of credentials for an unrelated service context.

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: 94% confidence
• Finding: The explicit check for a local .env file is part of custom credential extraction logic for XBY_APIKEY in a skill that claims to be for stock data. In context, this makes the mismatch more dangerous because it suggests the component may intentionally source credentials for a different service than the one users expect.

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: 95% confidence
• Finding: This function is explicitly designed to persist an API key into plaintext .env storage, which increases the likelihood of credential leakage through source control, local compromise, backups, or accidental sharing. In a mismatched skill context, storing secrets for an unrelated service further elevates trust and provenance concerns.

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: 95% confidence
• Finding: The function advertises that it sets and persists the API key to .env, reinforcing insecure plaintext secret storage as a normal workflow. This creates unnecessary credential exposure risk and is especially concerning because the key name and service identity do not match the advertised stock-data skill.

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 only a lower bound, so builds may resolve to different versions over time. This weakens supply-chain control and reproducibility, and can unexpectedly introduce vulnerable or breaking upstream releases into the skill.

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: Using an unpinned pydantic version means the installed package can drift as new releases are published. That increases supply-chain risk and makes deployments non-reproducible, which can accidentally pull in vulnerable or incompatible versions.

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: An unpinned pydantic-settings dependency allows future versions to be installed without review. This creates reproducibility problems and increases exposure to upstream regressions or newly introduced vulnerable versions.

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: Leaving python-dotenv unpinned allows dependency resolution to vary over time, reducing determinism and increasing supply-chain risk. Even if no exploit is present today, future installs may silently pick up vulnerable or incompatible releases.

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: 93% confidence
• Finding: The allowed range requests>=2.31.0 includes requests 2.31.0, which has published advisories, so an installation may resolve to a known-vulnerable version depending on environment or cache state. In a network-facing stock data service, requests is likely used to fetch remote data, making flaws in URL handling, credential handling, or session security more relevant than in an offline tool.

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: 79% confidence
• Finding: The version range python-dotenv>=1.0.1 permits installation of python-dotenv 1.0.1, which has an advisory related to symlink following in set_key. This is lower risk here because a stock data service typically uses dotenv for local configuration loading rather than writing attacker-controlled .env files, but the vulnerable version is still technically allowed.

Static analysis

No suspicious patterns detected.