Recharge / Renew of Skills | 技能账户充值/续费

• Outcome: Review
• Latest audit: Jul 10, 2026 · 10:26 AM UTC
• Version: 1.0.23

Overview

This payment skill broadly matches its stated purpose, but it handles real payments, account state, and credentials in ways that are too sensitive and under-scoped to approve without review.

Install only if you trust the publisher and are comfortable with this skill creating real Alipay payment orders, contacting LifeEmergence services, and storing account credentials locally. Before production use, require verified Alipay server-side callbacks, real authentication for token issuance, removal of mock/demo payment paths, no plaintext API key output, and explicit permission documentation.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Behavioral AST: exec() Call, eval() Call, Dynamic Import
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (65)

os.system() or os exec-family call

High

• Category: Dangerous Code Execution

Content

# 步骤 5: 创建订单
    print_section("步骤 5: 创建充值订单")
    order_id = f"ORD{os.popen('date +%Y%m%d%H%M%S').read().strip()}"
    print(f"✅ 订单创建成功")
    print(f"   订单 ID: {order_id}")
    print(f"   订单金额：¥{selected_amount}")

• Confidence: 89% confidence
• Finding: The script spawns a shell via os.popen() just to obtain a timestamp for an order ID. Even though the command string is constant here, invoking a shell in a payment-related flow adds unnecessary command-execution capability and increases risk if the code is later modified to include variable input or run in a sensitive environment.

os.system() or os exec-family call

High

• Category: Dangerous Code Execution

Content

# TODO: 这里需要调用真实的云端 API 创建订单
    # 现在使用模拟数据
    order = {
        "orderId": f"ORD{os.popen('date +%Y%m%d%H%M%S').read().strip()}",
        "amount": amount,
        "uses": uses,
        "detail": detail,

• Confidence: 90% confidence
• Finding: The code spawns a shell via os.popen('date +%Y%m%d%H%M%S') just to generate a timestamp-based order ID. Even though the command string is constant and not directly user-controlled here, invoking a shell in a payment flow is unnecessary and expands the attack surface by depending on PATH/shell behavior and command execution in a sensitive context.

Dynamic attribute access via getattr()

Low

• Category: Dangerous Code Execution

Content

if filters:
                for key, value in filters.items():
                    query = query.filter(getattr(self.__model__, key) == value)

            if offset:
                query = query.offset(offset)

• Confidence: 78% confidence
• Finding: This code applies filters using getattr(self.__model__, key) where key comes from the caller-provided filters dictionary, allowing unvalidated selection of model attributes. While SQLAlchemy prevents classic SQL injection here, an attacker or unintended caller can probe or filter on sensitive/internal columns and trigger exceptions or unauthorized query behavior if upstream input is not strictly constrained. In a payment-related skill that also stores identity and token fields, broad generic filtering is more dangerous because it can expose or facilitate access to user/account metadata beyond the intended business operation.

Dynamic attribute access via getattr()

Low

• Category: Dangerous Code Execution

Content

if filters:
                for key, value in filters.items():
                    query = query.filter(getattr(self.__model__, key) == value)

            return query.scalar()
        finally:

• Confidence: 78% confidence
• Finding: As with list(), this count() method accepts arbitrary filter keys and resolves them dynamically against the model, creating an overly generic query surface. Even without raw SQL injection, this can enable unauthorized inference about the existence or volume of records matching sensitive fields such as usernames, emails, or token-associated accounts if external input reaches this method. The payment/account context increases risk because record enumeration can support account discovery and privacy leakage.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 86% confidence
• Finding: The skill advertises and documents capabilities that require environment access, file I/O, networking, and shell execution, but it declares no permissions. That creates a transparency and policy-enforcement gap: a host may grant broader effective access than users expect, and reviewers cannot accurately assess the blast radius from the manifest alone.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The stated purpose is payment and balance lookup, but the documentation indicates substantially broader behavior including credential persistence, request-layer API key injection, token/auth service examples, background polling, and test/simulated payment flows. This mismatch is dangerous because operators and users may authorize a narrowly scoped payment skill while it also handles secrets, local persistence, and auxiliary services that enlarge the attack surface.

Context-Inappropriate Capability

Medium

• Confidence: 87% confidence
• Finding: The documented payment callback executes a local Python subprocess using data derived from payment notifications, creating an unnecessary cross-runtime execution path inside a security-sensitive payment flow. Even though ProcessBuilder avoids simple shell injection, this design expands attack surface, enables abuse of local script execution from externally triggered callbacks, and can expose the host to denial-of-service, unsafe script behavior, or privilege-boundary issues if the script path, arguments, or called code are modified or mishandled.

Description-Behavior Mismatch

Medium

• Confidence: 84% confidence
• Finding: The skill performs platform fingerprinting by inspecting environment variables and working-directory markers unrelated to core payment processing. Environment inspection can expose deployment metadata and enable behavior that differs by host, which increases stealth and complicates review, especially when users are not informed this detection occurs.

Context-Inappropriate Capability

Medium

• Confidence: 88% confidence
• Finding: The fallback design introduces subprocess execution, temporary file creation, network download, and local file deletion just to render a QR code. These operations materially expand the attack surface for command misuse, unsafe file handling, and data leakage beyond the payment skill's core function.

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: The example login flow issues a bearer token based only on a phone number, while the comment explicitly notes password verification as TODO. In a payment-related skill, this effectively allows impersonation of any user who knows or guesses a phone number, enabling unauthorized account queries, recharge actions, and session creation.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: The payment success page is for a payment/account skill, but the visible branding and service text repeatedly identify an unrelated service ('小龙虾主厨'). In a payment flow, mismatched identity is a trust and integrity issue because it can mislead users about who processed the transaction, increase phishing/social-engineering risk, and cause users to disclose payment details or accept fraudulent-looking pages as legitimate.

Description-Behavior Mismatch

Medium

• Confidence: 97% confidence
• Finding: The documentation conflicts with the skill metadata by listing only three package types and omitting the required custom package. In a payment skill, this can mislead downstream agents or operators into presenting incomplete purchase options, causing unauthorized steering of user choices, billing disputes, or bypass of intended business controls around custom pricing.

Description-Behavior Mismatch

Medium

• Confidence: 95% confidence
• Finding: The code stores an API key to a local workspace file and, on first change, prints the full secret to user-facing output. For a payment/account-query skill, persisting and disclosing a credential materially expands the skill’s capability beyond billing workflow handling and creates a direct secret exposure path through logs, transcripts, screenshots, or shared workspace access.

Context-Inappropriate Capability

Medium

• Confidence: 97% confidence
• Finding: The skill writes the API key in plaintext to `data/smyx-api-key.txt` and later emits the full value in Markdown. Plaintext local storage plus disclosure is unjustified for the stated payment purpose and risks credential theft by any process, user, backup system, or log collector with workspace access.

Intent-Code Divergence

Medium

• Confidence: 90% confidence
• Finding: The payment success handler bypasses the documented remote callback flow and directly invokes an internal `skill.on_pay_notify(data)` with attacker-controllable payment fields, while constructing a synthetic `trade_no` and marking `trade_status` as `TRADE_SUCCESS`. In a payment skill, this is dangerous because any caller that can reach this function may be able to trigger account crediting or order completion without verified proof from the payment provider.

Context-Inappropriate Capability

Medium

• Confidence: 78% confidence
• Finding: The authenticated token statistics endpoint exposes operational security metadata such as active and blacklisted token counts that are not necessary for end-user payment flows. Even if authentication is required, any compromised or low-privilege account could use this information for reconnaissance against the authentication system and to infer system state.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The login endpoint issues a bearer token based only on a supplied phone number, despite the documentation implying password or equivalent authentication. This enables trivial account impersonation: an attacker who knows or guesses a victim’s phone number can obtain a valid token and access account data or initiate recharge/payment actions as that user.

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: The code presents a fabricated URL as if it were a real Alipay cashier flow, but it does not create a signed order through Alipay APIs or verify any merchant context. In a payment skill, this is dangerous because users or downstream agents may trust the link as legitimate payment infrastructure, enabling spoofed payment flows, false assumptions about payment state, or unsafe integration with callback logic.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The output tells users the payment will not actually deduct funds because it is a sandbox test, yet the URL targets the production excashier.alipay.com domain and no sandbox configuration is used. In a payment context this is especially dangerous because it can mislead users into initiating a real payment or trusting a live payment page under false safety claims.

Context-Inappropriate Capability

Medium

• Confidence: 84% confidence
• Finding: Executing a shell command to generate an order ID is not required for the stated purpose of a demo payment script and expands the script's privileges beyond what is needed. In a skill ecosystem, unnecessary execution primitives are especially risky because they can be abused, copied into production code, or mask more dangerous behavior.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: The demo prints merchant configuration values such as the Alipay app ID, gateway URL, and notify callback URL directly to stdout. While not necessarily exposing private keys, this unnecessarily discloses internal payment integration details that can aid reconnaissance, phishing, or targeted abuse of the payment flow, and it exceeds what is needed for a user-facing payment/account skill.

Intent-Code Divergence

Low

• Confidence: 86% confidence
• Finding: The output describes the amount as a '测试金额' while the same screen clearly states the payment is a real Alipay charge that will cause actual deduction. This mismatch can mislead operators or users into treating the payment as harmless testing, increasing the chance of unintended real transactions.

Context-Inappropriate Capability

Medium

• Confidence: 86% confidence
• Finding: This finding is substantively the same issue as AST5: a payment skill executes a shell command to create an order ID. In payment-related code, unnecessary shell execution is especially risky because it occurs in a high-trust workflow and normalizes command execution where safer in-process generation would suffice.

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: The module-level docstring says the priority is API key file first and explicit identity second, but the implemented logic in resolve_recharge_account() does the opposite. In a payment/identity-resolution skill, this discrepancy is dangerous because upstream callers and reviewers may rely on the documented trust model, leading to charges or account actions being routed to an unintended account when an explicit parameter is supplied.

Intent-Code Divergence

Medium

• Confidence: 75% confidence
• Finding: The module-level documentation promises sensitive key material will remain only in process memory, but the code extracts key-related material from the order and passes it to a persistence helper. Even if this is API-key material rather than the exact private key, persisting credentials contrary to documented handling increases the risk of secret exposure and indicates unsafe secret-management assumptions in a payment flow.

VirusTotal

VirusTotal engine telemetry is currently stale for this artifact.

Static analysis

Detected: suspicious.install_untrusted_source

Install source points to URL shortener or raw IP.

Warn

• Code: suspicious.install_untrusted_source
• Location: skills/smyx_common/scripts/config-dev.yaml:2