Back to skill

Security audit

代码审查工具

Security checks for vulnerabilities and agentic risk

Overview

This appears to be a remote code-review skill, but it has enough mismatch and secret/data-handling concerns that users should review it carefully before installing.

Install only if you are comfortable sending reviewed code, diffs, file paths, and review text to the Xiaobenyang remote API and storing an XBY_APIKEY in a local .env file. Avoid using it on confidential repositories unless you have reviewed the provider, retention terms, and credential handling, and consider fixing the gaokao documentation/configuration leftovers before trusting it in production.

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
87% confidence
Finding
The skill advertises capabilities that imply access to environment variables, file read/write, and network operations, yet it declares no permissions. This creates a transparency and sandboxing problem: users and hosting platforms cannot accurately assess what the skill may access, increasing the risk of secret exposure, unintended file modification, or outbound data transmission.

Description-Behavior Mismatch

High
Confidence
98% confidence
Finding
The skill is presented as a code review tool, but its workflow and project structure describe a different gaokao/school-query skill and require collecting an external API key. This mismatch is highly suspicious because it can trick users into providing secrets or authorizing network actions unrelated to the stated purpose, a classic case of deceptive capability masking.

Intent-Code Divergence

High
Confidence
97% confidence
Finding
The documentation says the model should call code-review functions, but the concrete example instead calls `search_schools`, which belongs to an unrelated domain. This contradiction can steer an agent into invoking unintended tools or sending user inputs to the wrong backend, making data exfiltration or unauthorized actions more plausible in context.

Intent-Code Divergence

Medium
Confidence
96% confidence
Finding
The Settings docstring describes an unrelated '高考' skill rather than the declared code review tool, which is a strong indicator of code reuse, mispackaging, or hidden functionality. In a security-sensitive agent skill, this mismatch undermines trust boundaries and suggests the configuration may direct data or credentials to a service unrelated to the user-visible purpose.

Description-Behavior Mismatch

High
Confidence
99% confidence
Finding
The configuration is for an unrelated XBY gaokao service, including a remote base URL and service-specific identifiers, despite the skill being presented as a code review tool. This creates a serious risk that user data, prompts, or credentials intended for code review are instead routed to an unrelated third-party endpoint, which could enable unauthorized exfiltration or deceptive behavior.

Context-Inappropriate Capability

Medium
Confidence
94% confidence
Finding
The module includes functionality to persist API keys into a local .env file even though that capability is not clearly justified by a code review skill. Storing secrets on disk expands the attack surface by leaving recoverable credentials in the workspace, backups, logs, or other tooling that may access project files.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The code silently writes the provided API key to both .env and the current process environment without any visible disclosure, confirmation, or consent mechanism. This is dangerous because users may believe they are supplying a transient credential while the skill persists it locally, increasing the risk of accidental leakage through source control, diagnostics, or other local access.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The function transmits arbitrary source code to an external API without any disclosure, consent flow, or visible guardrails in this file. In a code-review tool context, the submitted code may contain proprietary logic, credentials, or other sensitive material, so silent exfiltration to a third-party service creates a real confidentiality risk.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
Git diffs often contain newly added secrets, security fixes, internal paths, and unreleased product details; sending them to an external API without warning materially increases data leakage risk. In this skill's context, diff review is a core feature, so the absence of disclosure and controls makes the issue more dangerous because sensitive changes are especially likely to pass through this path.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
This function sends both file paths and file contents to an external API without explicit disclosure. File paths can reveal internal project structure, usernames, or environment details, and file contents may include credentials or proprietary code, making this a meaningful confidentiality exposure in a code-review server.

Missing User Warnings

Low
Confidence
80% confidence
Finding
Although parsing review text seems lower risk than sending source code or diffs, review text can still contain sensitive excerpts, copied code, or internal findings. Sending that text externally without disclosure is still a confidentiality issue, just with typically lower impact than the other review functions.

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
93% confidence
Finding
This code forcibly reads XBY_APIKEY directly from a local .env file in custom logic, bypassing normal settings behavior and explicitly targeting a credential for an unrelated service. In the context of a code review tool, this increases the likelihood of unauthorized credential collection or misuse, especially given the broader service mismatch in the file.

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
93% confidence
Finding
Opening and reading the entire .env file to locate XBY_APIKEY is a direct secret-access behavior that is difficult to justify for the stated code review purpose. Because the skill appears wired to a different service, this file read materially raises the risk of collecting credentials from the local environment under misleading pretenses.

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
91% confidence
Finding
The function is explicitly designed to save an API key into a .env file, creating durable local secret storage within the project directory. For a code review skill, this is an unnecessary and risky credential-handling capability unless clearly disclosed and justified, because it can expose secrets through file access, backups, or accidental repository inclusion.

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
This function wraps API-key setting with automatic persistence to .env, making long-term secret storage part of normal operation. In the context of a mislabeled skill with unrelated service configuration, this behavior is especially concerning because it can normalize collecting and retaining credentials users did not expect to store locally.

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
94% confidence
Finding
The dependency uses a lower-bound specifier instead of a pinned version, which makes builds non-reproducible and can introduce unexpected or malicious upstream changes during installation. In a code review/MCP server context, this increases supply-chain risk because the tool may be deployed in varied environments and automatically pull newer dependency 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
94% confidence
Finding
The pydantic package is unpinned, so installs may resolve to different versions over time, reducing reproducibility and increasing exposure to supply-chain regressions or newly introduced malicious releases. Because this skill is a server-side tool component, dependency drift can affect validation logic and operational security unexpectedly.

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
93% confidence
Finding
Using pydantic-settings with only a minimum version allows future releases to be installed without review, which is a common software supply-chain weakness. In this tool, configuration handling is security-relevant, so unexpected package behavior changes could alter environment parsing or secret handling.

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
94% confidence
Finding
The python-dotenv dependency is not pinned, creating non-deterministic builds and the possibility of ingesting unreviewed upstream changes. Since dotenv libraries often interact with configuration files and secrets, supply-chain compromise or breaking behavior could have security implications for the service.

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
97% confidence
Finding
The requirement permits requests 2.31.0, a version with published advisories including credential leakage via malicious URLs and session verification issues. Even though the specifier is >=2.31.0 rather than ==2.31.0, the vulnerable version remains installable, so affected environments could deploy an exploitable package if resolution selects that version.

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
88% confidence
Finding
The requirement permits python-dotenv 1.0.1, which has a reported symlink-following issue in set_key that can lead to arbitrary file overwrite in affected usage patterns. The risk is somewhat context-dependent because exploitation requires the application to call the vulnerable functionality on attacker-influenced paths, but the vulnerable version is still allowed by the dependency specifier.

Static analysis

No suspicious patterns detected.