Back to skill

Security audit

Logo提取处理工具

Security checks for vulnerabilities and agentic risk

Overview

The skill mostly does what it claims, but it requires and persistently stores an API key in a local .env file and has copy-paste documentation/config mismatches that users should review before installing.

Install only if you trust the XiaoBenYang service and are comfortable giving it a dedicated API key. Use a low-privilege key if possible, expect it to be saved in plaintext as XBY_APIKEY in .env, and remove or rotate that key when you no longer use the skill.

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 (17)

Lp3

Medium
Category
MCP Least Privilege
Confidence
91% confidence
Finding
The skill appears to use environment access, local file read/write, and network capabilities while declaring no permissions, which breaks transparency and prevents informed consent or policy enforcement. In this context, the omission is more dangerous because the skill also instructs collecting and persisting an API key, so undeclared file and env access could be used to store or expose credentials unexpectedly.

Description-Behavior Mismatch

High
Confidence
95% confidence
Finding
The documentation says this is a logo extraction skill, but the workflow example references a different 'school search/gaokao' skill and mismatched tool calls. This kind of semantic mismatch is dangerous because it can cause operators or agents to invoke the wrong functions, mishandle user input, or trust behavior that does not match the stated purpose, increasing the risk of unauthorized data handling or confusion-driven misuse.

Intent-Code Divergence

Medium
Confidence
88% confidence
Finding
The statement that code 'only calls the API' conflicts with instructions to write configuration locally via set_api_key(), which materially changes the trust model. This is risky because users and reviewers may underestimate the skill's ability to persist secrets on disk, making credential retention and local exposure more likely.

Description-Behavior Mismatch

High
Confidence
98% confidence
Finding
The file belongs to a purported logo extraction tool, yet it forcibly reads, stores, and exposes an unrelated credential named XBY_APIKEY tied to a different apparent product context ('GAOKAO'). This strong mismatch between declared functionality and credential handling suggests hidden secondary behavior or credential collection beyond what the skill needs, creating a serious trust and exfiltration risk.

Context-Inappropriate Capability

Medium
Confidence
91% confidence
Finding
The code persistently stores an API key in a local .env file even though the stated skill purpose does not justify long-term secret storage. Writing secrets to disk increases the chance of accidental disclosure through source control, backups, logs, local compromise, or multi-user environments.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The skill explicitly instructs the agent to request an API key from the user and save it, but provides no warning about storage location, retention, masking, or disclosure risks. In this context, the danger is heightened because the skill also implies file and environment access, so collected credentials may be persisted or exposed without the user's informed consent.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The function silently writes the supplied API key into .env and exports it into the process environment without any confirmation or user-facing warning. This can cause users or higher-level agents to disclose and persist secrets unintentionally, especially when they believe they are interacting with a logo-processing utility.

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 explicitly and forcibly opens .env to extract XBY_APIKEY outside the normal settings flow, despite the skill claiming to be a logo tool. This custom secret-reading path is suspicious because it bypasses ordinary transparent configuration patterns and targets a credential unrelated to the declared functionality.

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 file existence check is part of an intentional credential access flow aimed at reading .env contents for a mismatched API key. In context, this contributes to unauthorized or unjustified secret access because the skill's advertised purpose gives no reason to inspect local secret files for unrelated credentials.

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
90% confidence
Finding
This function is explicitly designed to persist an API key into .env, creating a durable secret on disk in a project associated with unrelated functionality. That broadens exposure to accidental disclosure and is especially concerning because users would not expect a logo-processing tool to manage unrelated credentials this way.

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 API-setting helper wraps credential persistence as normal application behavior without clear security boundaries, encouraging silent long-term storage of secrets. In the context of a mismatched skill, this increases the chance that operators unknowingly entrust sensitive credentials to code that does not need them for its stated purpose.

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
97% confidence
Finding
The dependency is specified with a lower bound only (`requests>=2.31.0`), which allows installation of any future version and makes builds non-reproducible. This increases supply-chain risk because a later release could introduce breaking changes or a compromised package version without 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
97% confidence
Finding
The dependency is unpinned (`pydantic>=2.7.0`), so environments may resolve different versions over time. This weakens reproducibility and can expose the project to unreviewed upstream releases or dependency confusion/supply-chain issues.

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
97% confidence
Finding
Using `pydantic-settings>=2.2.0` without an upper bound or exact pin means future installs may pull newer versions automatically. That creates non-deterministic builds and increases exposure to malicious or vulnerable upstream releases.

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
97% confidence
Finding
The package `python-dotenv>=1.0.1` is not pinned, so deployment may consume different versions over time. In package-managed environments this is a classic low-severity supply-chain hygiene issue because it reduces reproducibility and reviewability of installed code.

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
95% confidence
Finding
The requirement permits `requests` 2.31.0 and the static analysis identifies that version as having multiple published advisories. Because this skill fetches remote website content by URL, a vulnerable HTTP client is more relevant than usual: malformed or attacker-controlled URLs and responses are part of the expected threat surface.

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 dependency range allows installation of `python-dotenv` 1.0.1, which the scanner reports as affected by a symlink-following arbitrary file overwrite issue in `set_key`. This is only directly dangerous if the skill uses `set_key` on attacker-influenced paths or runs in an environment where local filesystem manipulation is in scope, so the practical risk is lower without additional evidence of that usage.

Static analysis

No suspicious patterns detected.