Back to skill

Security audit

动态提示生成服务

Security checks for vulnerabilities and agentic risk

Overview

This skill is an API-backed prompt generator, but it handles a third-party API key and sends user input to a remote service with weak local secret handling.

Install only if you trust Xiaobenyang with the API key and any project, PRD, or bug context you provide. Prefer setting XBY_APIKEY through a managed environment or secret store instead of letting the skill write it to .env, make sure .env is not committed, and avoid sending confidential code or business details unless that third-party service is acceptable for your use case.

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 documentation indicates capabilities to read environment variables, read/write local files, and send data over the network, yet it declares no permissions. This is dangerous because it hides the real trust boundary from users and reviewers, especially since the skill explicitly requests, stores, and later uses an API key with a remote service.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The advertised function is local dynamic prompt/template generation, but the documented behavior includes collecting and persisting an API key and sending user data to an external API. This mismatch can mislead users into disclosing secrets or sensitive project context under false assumptions about local-only processing.

Description-Behavior Mismatch

High
Confidence
97% confidence
Finding
The skill requires the agent to obtain an API key from the user, persist it locally, and use a remote service for all functionality, despite being framed as a prompt/template generator. This creates a secret-handling and exfiltration risk, because user prompts, project context, and credentials may be transmitted to a third party without clear upfront disclosure.

Description-Behavior Mismatch

High
Confidence
90% confidence
Finding
References to unrelated gaokao/school-search behavior in the workflow/project structure indicate copy-paste drift or a repurposed codebase whose actual behavior may differ from the advertised skill. Such inconsistencies undermine trust and increase the chance of hidden or unintended functionality, including misuse of user inputs or credentials.

Description-Behavior Mismatch

Medium
Confidence
89% confidence
Finding
This module handles, stores, and exposes an external API key even though the stated skill purpose is dynamic prompt/template generation. The issue is not that configuration exists at all, but that persistent credential management broadens the trust boundary and creates unnecessary secret-handling risk for a skill whose declared function does not obviously require local secret persistence.

Context-Inappropriate Capability

Medium
Confidence
92% confidence
Finding
The code writes the API key directly into a local .env file, creating a plaintext secret at rest on disk. If the workspace is shared, backed up, logged, or accidentally committed, the credential can be exposed without any further exploit.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The function silently persists a sensitive API key to .env without any user-facing disclosure or confirmation. This undermines informed consent and increases the chance that users unknowingly leave plaintext credentials on disk where other tools, users, or version control may access them.

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
86% confidence
Finding
Manually reading .env to extract XBY_APIKEY duplicates the framework's settings loading and directly processes plaintext credentials from disk. This increases attack surface, bypasses more controlled configuration handling, and normalizes local secret scraping behavior in a skill whose purpose does not justify it clearly.

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
86% confidence
Finding
The existence check gates a direct read of .env for credentials, reinforcing a design where secrets are expected in plaintext local files. In shared or developer environments, this increases the chance of accidental exposure through file access, backups, or repository mistakes.

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
93% confidence
Finding
This function is explicitly designed to persist an API key into .env, creating long-lived plaintext secret storage on disk. That expands the blast radius of a credential compromise beyond the current session and is especially unjustified for a prompt-generation skill.

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 design encourages callers to set and persist the key as a normal operation, making insecure secret storage part of the intended workflow. This increases the likelihood of accidental credential retention and leakage during routine use.

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
96% confidence
Finding
The dependency is specified with a lower-bound only (`requests>=2.31.0`), which makes builds non-reproducible and allows future incompatible or compromised releases to be installed without review. In a prompt-generation service that may make outbound HTTP requests, uncontrolled dependency drift increases supply-chain risk and can unexpectedly introduce 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
Using `pydantic>=2.7.0` without an upper bound or exact pin permits unreviewed future versions to be installed, which can break validation behavior or introduce security defects. Because this service appears modular and dynamically assembles prompts/templates, schema-validation dependencies are security-relevant and should be reproducible.

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` is unpinned, so deployments may pull different versions over time, increasing the chance of unexpected configuration parsing changes or newly introduced flaws. Since settings libraries often process environment-derived secrets and configuration, supply-chain control is important.

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
96% confidence
Finding
The package `python-dotenv>=1.0.1` is not pinned, making installations non-deterministic and exposing the service to future package changes or malicious upstream releases. This is especially relevant for a service likely reading environment configuration, where dependency behavior directly affects secret handling and filesystem interactions.

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 requirement allows installation of `requests` 2.31.0, a version with published advisories including credential leakage and request verification issues. In a service that may fetch remote content or interact with external systems, these flaws can expose credentials, weaken transport security, or enable other network-originated attacks depending on usage.

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
82% confidence
Finding
`python-dotenv` 1.0.1 is flagged for a symlink-following issue in `set_key`, which can permit arbitrary file overwrite if the vulnerable API is used with attacker-influenced paths. The impact depends on whether this skill actually invokes that functionality, but keeping a known-vulnerable configuration library increases risk unnecessarily.

Static analysis

No suspicious patterns detected.