Payment Skill

• Outcome: Review
• Latest audit: Sep 12, 2026 · 8:24 AM UTC
• Version: 1.0.3

Overview

The skill broadly matches its payment purpose, but it should be reviewed before installation because it can handle payment secrets and initiate refunds without strong built-in safeguards.

Install only if you trust the publisher and can enforce operational controls outside the skill: require HTTPS-only API endpoints, do not run setup with real payment credentials in the environment, rotate any credentials whose fragments may have appeared in logs, update vulnerable dependencies, and require an explicit approval workflow for refunds before allowing production use.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (6)

T09 · Insecure Skill Coding Practices

Error

• Location: src/payment_api_client.py:52
• Finding: Payment API credentials may be transmitted over plaintext HTTP<![CDATA[ ## Vulnerability Details **File Location**: `src/config_loader.py:86-104`, `src/payment_api_client.py:52-74` **Vulnerability Type**: Unvalidated transport security for sensitive API requests **Risk Level**: High ### Vulnerable Code ```python # src/config_loader.py:86-104 config = { "api_key": os.getenv("PAYMENT_API_KEY"), "api_secret": os.getenv("PAYMENT_API_SECRET"), "api_url": os.getenv("PAYMENT_API_URL"), "timeout": int(os.getenv("PAYMENT_API_TIMEOUT", "30")) if os.getenv("PAYMENT_API_TIMEOUT") else 30, } env_config = ConfigLoader.load_env_file(env_name) if not config["api_key"]: config["api_key"] = env_config.get("PAYMENT_API_KEY") if not config["api_secret"]: config["api_secret"] = env_config.get("PAYMENT_API_SECRET") if not config["api_url"]: config["api_url"] = env_config.get("PAYMENT_API_URL") if not config["api_url"]: config["api_url"] = "https://api.zlclaw.com" ``` ```python # src/payment_api_client.py:52-74 url = f"{self.api_url}/{endpoint}" signature = self._generate_signature(method, endpoint, data) timestamp = str(int(time.time())) headers = { "Authorization": f"Bearer {self.api_key}", "X-Signature": signature, "X-Timestamp": timestamp, "Content-Type": "application/json" } try: async with self.session.request( method, url, json=data, headers=headers, timeout=aiohttp.ClientTimeout(total=self.timeout) ) as response: ``` ### Technical Analysis The application accepts `PAYMENT_API_URL` from the process environment or a configuration file without validating its scheme. Although the default endpoint uses HTTPS, a configured value beginning with `http://` is accepted and used directly. Every request includes the payment API key in an `Authorization` header. Payment creation and refund requests also carry transaction data in the request body. HMAC signing provides integrity only to parties that cannot recover or replace the request context; it does ...[truncated 1211 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Parse `PAYMENT_API_URL` using `urllib.parse.urlparse`. 2. Reject every scheme except `https`. 3. Reject URLs containing embedded user information, fragments, malformed ports, or unexpected path components. 4. Maintain an allowlist of approved payment API hostnames where deployment requirements permit it. 5. Keep TLS certificate verification enabled and do not expose a configuration option that silently disables it. 6. Consider certificate or public-key pinning for tightly controlled payment infrastructure. 7. Add automated tests confirming that `http://`, malformed, and unapproved endpoints are rejected before any credentials are transmitted. 8. Use narrowly scoped and rotatable payment API credentials to reduce the impact of accidental disclosure. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: src/payment_skill.py:220
• Finding: Refund approval requirement is declared but not enforced<![CDATA[ ## Vulnerability Details **File Location**: `src/payment_skill.yaml:51-59`, `src/payment_skill.py:220-242`, `skill_cli.py:192-201` **Vulnerability Type**: Missing authorization enforcement for a financial operation **Risk Level**: High ### Vulnerable Code ```yaml # src/payment_skill.yaml:51-59 - name: refund_payment description: 发起退款 timeout: 10000 rate_limit: requests_per_minute: 30 requires_approval: true ``` ```python # src/payment_skill.py:220-242 if not transaction_id: raise ValueError("交易 ID 不能为空") if amount is not None and amount <= 0: raise ValueError("退款金额必须大于 0") result = await self.api_client.refund_payment( transaction_id=transaction_id, amount=amount ) response = { "success": True, "refund_id": result.get("id"), "status": result.get("status"), "amount": result.get("amount"), "currency": result.get("currency"), "created_at": result.get("created_at") } ``` ```python # skill_cli.py:192-201 elif args.command == 'refund_payment': params = { 'transaction_id': args.transaction_id } if args.amount: params['amount'] = args.amount if args.reason: params['reason'] = args.reason ``` ### Technical Analysis The Skill metadata marks `refund_payment` as requiring approval, but this requirement is not enforced in the executable control path. The CLI accepts a transaction ID and optional amount, and `PaymentSkill.refund_payment` immediately sends an authenticated refund request after basic parameter validation. Metadata-based approval is not a security boundary unless the runtime guarantees enforcement. Direct invocation of `skill_cli.py`, direct use of `PaymentSkill`, or a host that does not interpret `requires_approval` bypasses the declared control entirely. There is no approval token, authorized-user identity, confirmation challenge, or server-verifiable authorization artifact bound to the refund. ### Attack Path 1. An attacker, compromised Agent, or ...[truncated 859 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Enforce approval in executable code before invoking the payment API. 2. Require a short-lived, cryptographically signed approval token issued by a trusted authorization service. 3. Bind the approval token to the transaction ID, refund amount, merchant or account, requester identity, and expiration time. 4. Reject reused, expired, mismatched, or unsigned approval artifacts. 5. Perform the same authorization check on the payment server; client-side enforcement alone is insufficient. 6. Require explicit confirmation for full refunds where the amount is omitted. 7. Record immutable audit events containing the requester, approver, transaction, amount, and result. 8. Apply role-based access control and rate limits independently of manifest metadata. 9. Add tests proving that direct CLI and direct class invocations cannot initiate refunds without valid approval. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/diagnose.py:209
• Finding: Installation diagnostics disclose portions of payment credentials<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup.sh:80-82`, `scripts/diagnose.py:209-222` **Vulnerability Type**: Sensitive information exposure through terminal and CI logs **Risk Level**: Medium ### Vulnerable Code ```bash # scripts/setup.sh:80-82 if [ -f "$SCRIPT_DIR/diagnose.py" ]; then python3 "$SCRIPT_DIR/diagnose.py" else ``` ```python # scripts/diagnose.py:209-222 env_vars = [ "PAYMENT_API_KEY", "PAYMENT_API_SECRET", "PAYMENT_API_URL", "PAYMENT_LOG_LEVEL", ] for var in env_vars: value = os.getenv(var) if value: if "SECRET" in var or "KEY" in var: display_value = f"{value[:4]}...{value[-4:]}" else: display_value = value print_success(f"{var}: {display_value}") else: print_warning(f"{var}: 未设置") ``` ### Technical Analysis The documented setup script automatically executes the diagnostic utility after installing dependencies. The diagnostic reads payment credentials from the environment and prints the first and last four characters of values whose names contain `KEY` or `SECRET`. Terminal output is frequently retained in shell transcripts, CI/CD logs, support bundles, or remote session recordings. Revealing eight characters unnecessarily reduces credential entropy. If a credential is short, the prefix and suffix can overlap and disclose most or all of its content. This output is not required to establish whether a variable is configured; a Boolean set/not-set result is sufficient. ### Attack Path 1. An operator exports real payment credentials before running setup or runs setup in a CI environment containing those credentials. 2. `scripts/setup.sh` automatically invokes `scripts/diagnose.py`. 3. The diagnostic reads the credential values from the process environment. 4. It writes their first and last four characters to standard output. 5. The output is retained in terminal history, CI logs, or support diagnostics. 6. A person with access to ...[truncated 502 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Never print any characters from payment credentials. 2. Report only whether each sensitive variable is set, for example, `PAYMENT_API_KEY: configured`. 3. Keep non-sensitive values such as log level separate from credential diagnostics. 4. Avoid automatically inspecting secrets during package setup unless strictly necessary. 5. Mark CI jobs handling payment secrets as restricted and disable verbose command tracing. 6. Review and purge historical setup logs that may contain credential fragments. 7. Rotate credentials if fragments have already appeared in broadly accessible logs. 8. Add tests ensuring diagnostic output never contains any substring of configured secrets. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: src/security.py:115
• Finding: Weak encryption keys are silently accepted through zero padding<![CDATA[ ## Vulnerability Details **File Location**: `src/security.py:115-125` **Vulnerability Type**: Insecure cryptographic key derivation **Risk Level**: Medium ### Vulnerable Code ```python @classmethod def from_env(cls, env_key: str = "PAYMENT_ENCRYPTION_KEY") -> "DataEncryption": import os key_str = os.environ.get(env_key) if not key_str: raise ValueError(f"环境变量 {env_key} 未设置，生产环境必须提供加密密钥") key_bytes = key_str.encode()[:32].ljust(32, b'0') return cls(key_bytes) ``` ### Technical Analysis The constructor requires a 32-byte key, but `from_env` converts any nonempty string into 32 bytes by truncating long values and padding short values with predictable ASCII zero bytes. A one-character password therefore becomes a formally valid AES-256 key even though its effective entropy is extremely low. Padding does not constitute a password-based key derivation function. It creates deterministic, easily guessed keys and can make operators believe that AES-256 strength is being provided when security is actually limited by the original string. Truncating encoded Unicode input can also produce ambiguous or invalid key handling. AES-GCM is an appropriate authenticated encryption mode, but its security depends on unpredictable keys. The serialization of ciphertext, nonce, and tag with Base64 is normal and is not itself an exfiltration mechanism. ### Attack Path 1. An operator configures a short or human-memorable `PAYMENT_ENCRYPTION_KEY`. 2. `from_env` pads that value with predictable zero bytes. 3. Sensitive fields are encrypted using the resulting low-entropy AES key. 4. An attacker obtains encrypted output through storage exposure, logs, backups, or another application flaw. 5. The attacker constructs likely candidate strings, applies the same truncation and padding algorithm, and tests candidates using the GCM authentication tag. 6. A matching tag confirms the correct key and permits decryption of protected fields. ### Impact Asses ...[truncated 350 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Require exactly 32 cryptographically random bytes rather than padding arbitrary strings. 2. Store the key as validated Base64 or hexadecimal text and reject malformed or incorrectly sized values. 3. Generate keys using a cryptographically secure random generator and document a secure provisioning procedure. 4. If human-entered passphrases must be supported, derive keys using Argon2id or scrypt with a unique random salt and suitable cost parameters. 5. Use a managed secret store or key-management service in production. 6. Support key identifiers and controlled key rotation. 7. Fail closed when encryption is configured but key initialization fails; do not silently continue without encryption where confidentiality is required. 8. Add tests proving that short, oversized, malformed, and low-entropy encodings are rejected. ]]>

T08 · Insecure Dependencies

Warning

• Location: scripts/setup.sh:54
• Finding: Dependency installation does not verify package integrity<![CDATA[ ## Vulnerability Details **File Location**: `scripts/setup.sh:54-66`, `scripts/requirements.txt:1-16`, `scripts/requirements-py36.txt:1-28` **Vulnerability Type**: Unverified third-party package installation **Risk Level**: Medium ### Vulnerable Code ```bash # scripts/setup.sh:54-66 echo "Upgrading pip..." python3 -m pip install --upgrade pip echo "pip upgraded" echo "Installing dependencies..." if [ ! -f "$REQUIREMENTS_FILE" ]; then echo "Error: \"$REQUIREMENTS_FILE\" not found" exit 1 fi echo "Installing from $REQUIREMENTS_FILE..." pip install -r "$REQUIREMENTS_FILE" ``` ```text # scripts/requirements.txt:1-16 aiohttp==3.9.5 pydantic==2.7.0 pyyaml==6.0.1 python-dotenv==1.0.1 cryptography==42.0.5 pycryptodome==3.19.1 pytest==8.2.0 pytest-asyncio==0.23.6 pytest-cov==5.0.0 redis==5.0.1 ``` ### Technical Analysis The dependency files pin direct package versions, which reduces unexpected version changes, but installation does not verify package hashes or constrain package-index provenance. The setup script also upgrades pip to an unconstrained latest version. Consequently, security depends on the integrity of the configured package index, DNS/TLS trust, and every selected distribution artifact. A compromised mirror, misconfigured private index, or substituted artifact could provide malicious installation content. The Python 3.6 dependency set additionally relies on unsupported legacy runtime and package versions, increasing maintenance and exposure concerns. No malicious dependency is proven to be present in the reviewed files. The confirmed weakness is the absence of reproducible artifact verification in an installation script that executes network-retrieved packages. ### Attack Path 1. A user follows the documented setup procedure. 2. The script performs an unconstrained pip upgrade and resolves dependencies through the configured package index. 3. An attacker compromises or controls that index, mirror, or an equivalent package-reso ...[truncated 764 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Generate a fully resolved lock file containing cryptographic hashes for all direct and transitive dependencies. 2. Install with `pip install --require-hashes -r <locked-file>`. 3. Configure an explicitly trusted package index and prevent unintended fallback to public or extra indexes. 4. Pin the pip version rather than upgrading to an unconstrained latest release during setup. 5. Verify downloaded artifacts in a controlled build pipeline and deploy from an internal, immutable artifact repository. 6. Separate runtime dependencies from test and optional dependencies so production installs receive only required packages. 7. Retire Python 3.6 support and remove its legacy dependency manifest. 8. Run dependency vulnerability and license scanning in CI, and establish a regular update process. 9. Execute installation without administrative privileges and without production payment credentials in the environment. ]]>

T09 · Insecure Skill Coding Practices

Note

• Location: src/payment_api_client.py:55
• Finding: Request signature may use a different timestamp from the transmitted header<![CDATA[ ## Vulnerability Details **File Location**: `src/payment_api_client.py:55-64`, `src/payment_api_client.py:99-107` **Vulnerability Type**: Inconsistent authenticated-request construction **Risk Level**: Low ### Vulnerable Code ```python # src/payment_api_client.py:55-64 signature = self._generate_signature(method, endpoint, data) timestamp = str(int(time.time())) headers = { "Authorization": f"Bearer {self.api_key}", "X-Signature": signature, "X-Timestamp": timestamp, "Content-Type": "application/json" } ``` ```python # src/payment_api_client.py:99-107 timestamp = str(int(time.time())) message = f"{method}:{endpoint}:{timestamp}" if data: message += f":{json.dumps(data, sort_keys=True)}" ``` ### Technical Analysis The signature function obtains the current Unix timestamp internally, while `_request` independently obtains another timestamp for `X-Timestamp`. If execution crosses a one-second boundary between these calls, the header contains a timestamp different from the one included in the HMAC input. A server that reconstructs the signature using `X-Timestamp` will reject the request. This is primarily an availability and correctness defect rather than a direct privilege-escalation vulnerability. Repeatedly inducing the boundary condition may increase payment API failures, although reliable remote timing control is not demonstrated by the code alone. ### Attack Path 1. `_request` calls `_generate_signature`. 2. `_generate_signature` signs timestamp value `N`. 3. The system clock advances to `N+1` before control returns. 4. `_request` places timestamp `N+1` in `X-Timestamp`. 5. The server verifies the HMAC using the transmitted value `N+1`. 6. Verification fails because the client signed `N`, causing the health check or financial operation to be rejected. ### Impact Assessment The impact is intermittent denial of service or failed payment operations, including initialization health checks, payment creation, transaction qu ...[truncated 104 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Generate the timestamp exactly once in `_request`. 2. Pass that timestamp as an explicit argument to `_generate_signature`. 3. Construct the signature and `X-Timestamp` header from the same immutable value. 4. Define and document canonical JSON serialization, character encoding, endpoint formatting, and empty-body behavior. 5. Add unit tests around second-boundary transitions by injecting a controllable clock. 6. Consider adding a nonce or idempotency key where the payment API protocol supports replay protection. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Behavioral AST: exec() Call, eval() Call, Dynamic Import

Findings (37)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: Providing undeclared generic validation and encryption/decryption utilities while lacking core payment functionality is a strong description-behavior mismatch. While those helpers are not inherently malicious, hiding extra cryptographic or data-processing capabilities inside a payment-branded skill can enable misuse and defeats informed consent by the operator.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence
• Finding: Providing undeclared generic validation and encryption/decryption utilities while lacking core payment functionality is a strong description-behavior mismatch. While those helpers are not inherently malicious, hiding extra cryptographic or data-processing capabilities inside a payment-branded skill can enable misuse and defeats informed consent by the operator.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 88% confidence
• Finding: Providing undeclared generic validation and encryption/decryption utilities while lacking core payment functionality is a strong description-behavior mismatch. While those helpers are not inherently malicious, hiding extra cryptographic or data-processing capabilities inside a payment-branded skill can enable misuse and defeats informed consent by the operator.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: Providing undeclared generic validation and encryption/decryption utilities while lacking core payment functionality is a strong description-behavior mismatch. While those helpers are not inherently malicious, hiding extra cryptographic or data-processing capabilities inside a payment-branded skill can enable misuse and defeats informed consent by the operator.

Known Vulnerable Dependency: aiohttp==3.6.3 — 16 advisory(ies): CVE-2026-54279 (aiohttp: Host-Only Cookies Become Domain Cookies After CookieJar Persistence); CVE-2026-34514 (AIOHTTP has CRLF injection through multipart part content type header constructi); CVE-2026-34517 (AIOHTTP has late size enforcement for non-file multipart fields causes memory Do) +13 more

High

• Category: Supply Chain
• Confidence: 98% confidence
• Finding: Pinning aiohttp to 3.6.3 introduces a dependency version with multiple published security advisories, including request/header handling and multipart-related issues. In a payment skill that likely performs network I/O, a vulnerable HTTP client materially increases exposure to denial of service, header injection, cookie handling, or other request-processing attacks.

Known Vulnerable Dependency: pydantic==1.8.2 — 2 advisory(ies): CVE-2024-3772 (Pydantic regular expression denial of service); CVE-2024-3772 (Pydantic regular expression denial of service)

High

• Category: Supply Chain
• Confidence: 95% confidence
• Finding: Pydantic 1.8.2 is flagged for a regular-expression denial-of-service issue. If this payment skill validates attacker-controlled input such as payment metadata, webhook payloads, or user fields, crafted input could trigger excessive CPU consumption and degrade availability.

Known Vulnerable Dependency: cryptography==3.4.8 — 16 advisory(ies): CVE-2023-50782 (Python Cryptography package vulnerable to Bleichenbacher timing oracle attack); GHSA-537c-gmf6-5ccf (Vulnerable OpenSSL included in cryptography wheels); GHSA-5cpq-8wj7-hf2v (Vulnerable OpenSSL included in cryptography wheels) +13 more

High

• Category: Supply Chain
• Confidence: 98% confidence
• Finding: cryptography 3.4.8 is associated with multiple advisories, including cryptographic weaknesses and vulnerable bundled OpenSSL components. In a payment-oriented skill, cryptographic assurance is central; outdated crypto dependencies can undermine confidentiality, integrity, and trust boundaries around secrets, tokens, or TLS-related operations.

Known Vulnerable Dependency: pycryptodome==3.10.4 — 2 advisory(ies): CVE-2023-52323 (PyCryptodome and pycryptodomex side-channel leakage for OAEP decryption); CVE-2023-52323 (PyCryptodome and pycryptodomex side-channel leakage for OAEP decryption)

High

• Category: Supply Chain
• Confidence: 97% confidence
• Finding: pycryptodome 3.10.4 is flagged for a side-channel issue affecting OAEP decryption. In a payment context, where encrypted secrets, tokens, or sensitive payloads may be processed, side-channel leakage can be especially serious because it may aid key recovery or plaintext inference under certain attack conditions.

Known Vulnerable Dependency: pytest==6.2.5 — 2 advisory(ies): CVE-2025-71176 (pytest has vulnerable tmpdir handling); CVE-2025-71176 (pytest has vulnerable tmpdir handling)

High

• Category: Supply Chain
• Confidence: 80% confidence
• Finding: pytest is a development/test dependency, so its vulnerable tmpdir handling is less likely to affect production runtime directly. However, it can still matter in CI, local testing, or shared build environments where malicious test inputs or filesystem manipulation could impact integrity or leak data.

Known Vulnerable Dependency: aiohttp==3.9.5 — 16 advisory(ies): CVE-2026-54279 (aiohttp: Host-Only Cookies Become Domain Cookies After CookieJar Persistence); CVE-2026-34514 (AIOHTTP has CRLF injection through multipart part content type header constructi); CVE-2026-34517 (AIOHTTP has late size enforcement for non-file multipart fields causes memory Do) +13 more

High

• Category: Supply Chain
• Confidence: 94% confidence
• Finding: The file pins aiohttp==3.9.5, and the static analysis reports multiple known advisories including CRLF injection and cookie-handling issues. In a payment-related skill, HTTP client security matters because outbound requests may carry tokens, session state, or sensitive transaction metadata, so vulnerable request parsing or cookie behavior can increase risk substantially.

Known Vulnerable Dependency: cryptography==42.0.5 — 11 advisory(ies): GHSA-537c-gmf6-5ccf (Vulnerable OpenSSL included in cryptography wheels); CVE-2024-12797 (Vulnerable OpenSSL included in cryptography wheels); GHSA-h4gh-qq45-vh27 (pyca/cryptography has a vulnerable OpenSSL included in cryptography wheels) +8 more

High

• Category: Supply Chain
• Confidence: 96% confidence
• Finding: cryptography==42.0.5 is reported to include vulnerable OpenSSL components in some wheels, which is particularly serious in a payment skill that likely relies on TLS, key handling, signatures, or encryption. Weaknesses in foundational crypto dependencies can undermine confidentiality and integrity even if the application code appears correct.

Known Vulnerable Dependency: pytest==8.2.0 — 2 advisory(ies): GHSA-6w46-j5rx-g56g; PYSEC-2026-1845

High

• Category: Supply Chain
• Confidence: 80% confidence
• Finding: pytest==8.2.0 is a known vulnerable dependency according to the reported advisories, but it is listed under test dependencies rather than production runtime. That reduces direct exploitability in deployed payment functionality, though it can still affect CI environments, developer systems, or any pipeline that processes untrusted test inputs.

Credential Access

High

• Category: Privilege Escalation

Content

配置字典
        """
        config_dir = ConfigLoader.get_config_dir()
        env_file = config_dir / f"{env_name}.env"
        
        if not env_file.exists():
            logger.warning(f"配置文件不存在: {env_file}")

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 85% confidence
• Finding: The skill advertises executable behavior involving environment access, file reads, network, and shell execution, yet the manifest does not declare any explicit tool scope such as permissions or allowed-tools. In a payment context, this is risky because the skill handles secrets and can run setup scripts, making it harder for a host or reviewer to constrain what the skill may access or execute.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The refund operation can trigger irreversible or financially destructive actions, but the documentation does not provide an explicit warning or confirmation requirement. In a payment skill, that omission raises the risk of accidental or unauthorized refunds initiated by an agent or user without understanding the consequences.

Natural-Language Policy Violations

Medium

• Confidence: 96% confidence
• Finding: The file’s natural-language description and all user-facing messages are written exclusively in Chinese, indicating the skill is designed to operate in a single language. There is no indication that the user can choose another language or that the Chinese-only constraint is required for a documented region-specific purpose.

Description-Behavior Mismatch

Medium

• Confidence: 89% confidence
• Finding: This script performs broad environment and project reconnaissance unrelated to core payment processing, including enumerating dependencies, project files, interpreter details, and configuration state. In a skill context, such host introspection increases the amount of internal metadata exposed to the operator or logs and can aid follow-on attacks or unauthorized profiling of the runtime environment.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

print_header("pip 版本检查")
    
    try:
        result = subprocess.run(
            [sys.executable, "-m", "pip", "--version"],
            capture_output=True,
            text=True

• Confidence: 70% confidence
• Finding: subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Context-Inappropriate Capability

Medium

• Confidence: 97% confidence
• Finding: The script reads payment-related environment variables, including API keys and secrets, and prints masked portions of their values. Even partial secret disclosure confirms presence, format, and fragments of credentials, which can leak into logs, screenshots, CI output, or support channels and materially weaken secret confidentiality.

Known Vulnerable Dependency: python-dotenv==0.19.0 — 2 advisory(ies): CVE-2026-28684 (python-dotenv: Symlink following in set_key allows arbitrary file overwrite via ); CVE-2026-28684 (python-dotenv reads key-value pairs from a .env file and can set them as environ)

Medium

• Category: Supply Chain
• Confidence: 85% confidence
• Finding: python-dotenv 0.19.0 has an advisory involving unsafe symlink handling in set_key/arbitrary file overwrite scenarios. While exploitability depends on whether the skill writes .env files or runs in an attacker-influenced filesystem context, the vulnerable version still represents a real supply-chain risk.

Known Vulnerable Dependency: python-dotenv==1.0.1 — 2 advisory(ies): CVE-2026-28684 (python-dotenv: Symlink following in set_key allows arbitrary file overwrite via ); CVE-2026-28684 (python-dotenv reads key-value pairs from a .env file and can set them as environ)

Medium

• Category: Supply Chain
• Confidence: 88% confidence
• Finding: python-dotenv==1.0.1 is flagged for a symlink-following issue in set_key that can enable arbitrary file overwrite in some usage patterns. While a requirements file alone does not prove the vulnerable API is used, including a version with known security issues is still a real dependency risk, especially if deployment or tooling modifies .env files during setup or runtime.

Natural-Language Policy Violations

Medium

• Confidence: 94% confidence
• Finding: The file's user-facing docstring, help text, and runtime messages are written in Chinese, which effectively imposes a specific language on users. The policy allows locale constraints only when justified or when the user is given a language choice, neither of which appears in this file.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: This code exposes a `refund_payment` command, which is an irreversible or safety-critical operation, but the CLI only labels it as '发起退款' and does not present any confirmation prompt or explicit warning at execution time. Although the command name indicates purpose, there is no user disclosure in the execution path that the action may reverse a prior transaction and affect funds.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: All user/developer-facing natural-language text in docstrings, log messages, and exception strings is written exclusively in Chinese, with no indication that language choice is configurable or limited to a justified locale-specific context. This can violate language/locale policy when the skill is expected to operate in a broader environment without explicit opt-in.

Context-Inappropriate Capability

Medium

• Confidence: 79% confidence
• Finding: The manifest describes a payment solution, but this module implements local configuration and secret discovery via os.getenv and direct reads of config/*.env files. While payment processing may need credentials, broad environment-variable and local file access is a separate capability not stated in the manifest and expands the skill's reach into host configuration.

Static analysis

No suspicious patterns detected.