tips

• Outcome: Review
• Latest audit: Sep 12, 2026 · 1:53 AM UTC
• Version: 1.0.0

Overview

This skill is a disclosed tipping/payment helper, but its payment flow has under-scoped financial authorization that users should review before installing.

Install only if the surrounding payment system supplies and verifies the intended recipient and payment provider outside this skill. Users should confirm the amount, recipient, and payment link domain before paying, because this skill itself does not bind those details in its confirmation flow.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:35
• Finding: Payment authorization is not bound to the intended recipient## Vulnerability Details **File Location**: `SKILL.md`, lines 35-69 **Vulnerability Type**: Missing recipient validation in a financial workflow **Risk Level**: High ### Evidence ```markdown > 不收集打赏对象，忽略用户消息中提到的收款方信息. ``` ```markdown 5. **调用支付 skill（payment）**，传入以下参数： ``` amount: {打赏金额} order_type: "tip" description: "打赏 {amount} 元" ``` ``` The first instruction states that recipient information must not be collected and that any payee specified by the user must be ignored. The payment request consequently contains only an amount, an order type, and a generic description. ### Technical Analysis A payment authorization should bind all security-relevant transaction attributes to the user's confirmation, including the amount, currency, recipient identity, and transaction purpose. This workflow confirms only the amount and then invokes the payment skill without a recipient identifier. Ignoring recipient information creates a confused-deputy risk: the user may believe that a tip is being sent to a named streamer or creator, while the downstream payment system selects a default, implicit, or otherwise unrelated recipient. The confirmation prompt does not expose that discrepancy. ### Attack Path 1. An attacker persuades a victim to tip a particular streamer, creator, or account. 2. The victim names that recipient when invoking the skill. 3. The skill intentionally discards the supplied recipient information. 4. The user is asked to confirm only the amount. 5. The generic payment request is sent without any payee identifier. 6. If the downstream payment skill uses an attacker-controlled, incorrect, or default recipient, the order is created for that recipient despite the victim's contrary understanding. Exploitation depends on how the downstream payment skill resolves requests that omit a recipient, but this skill provides no mechanism to detect or prevent recipient substitution. ### Im ...[truncated 410 chars]
• Remediation: ## Remediation Suggestions - Require an immutable recipient identifier, such as a merchant ID, creator ID, or payment account ID. - Resolve human-readable recipient names through a trusted registry rather than accepting arbitrary payment destinations. - Include the verified recipient name and identifier in the final confirmation prompt. - Pass the verified recipient identifier explicitly to the payment skill. - Require the payment skill to reject requests that lack a valid recipient instead of applying an implicit default. - Bind amount, currency, recipient, and purpose into a transaction summary or authorization token. - Invalidate confirmation if any bound transaction attribute changes. - Log the confirmed recipient and the recipient returned by the payment provider, and reject any mismatch.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:102
• Finding: Unvalidated downstream payment links are presented as successful transactions## Vulnerability Details **File Location**: `SKILL.md`, lines 102-109 **Vulnerability Type**: Untrusted payment URL propagation and misleading transaction status **Risk Level**: High ### Evidence ```markdown **支付成功后（展示支付 skill 返回的 tradeCode 和 tradeLink）：** ``` ✅ 打赏成功！已为您创建打赏订单。 🔢 交易码：{tradeCode} 🔗 支付链接：{tradeLink} 请复制交易码或点击链接完成支付，感谢您的慷慨！🎉 ``` ``` The example later in the document supplies the following external destination: ```text https://pay-h5.4199191.xyz/pyment/62254562871846512 ``` The external domain is not, by itself, proof of malicious ownership. However, the workflow specifies no validation, allowlist, origin binding, or integrity check before displaying a downstream-provided URL and encouraging the user to open it. ### Technical Analysis The payment skill's output crosses a trust boundary. Treating `tradeLink` as display-ready allows a compromised, spoofed, or misconfigured downstream skill to provide an arbitrary destination. A malicious link could imitate a payment page and solicit credentials, card data, authentication codes, or additional transfers. The response also labels the operation as successful while simultaneously telling the user to follow the link to complete payment. Order creation and completed payment are distinct states. This wording can prevent users from recognizing failures or suspicious follow-up requests and can create inaccurate transaction records. ### Attack Path 1. An attacker compromises, replaces, or misconfigures the downstream payment skill or its response source. 2. The victim confirms a tip. 3. The downstream component returns an attacker-controlled `tradeLink`. 4. This skill displays the URL without validating its scheme, hostname, path, or association with the created order. 5. The victim follows the apparently trusted payment link. 6. The attacker presents a phishing or fraudulent payment page and captures sensitive financial information or induce ...[truncated 628 chars]
• Remediation: ## Remediation Suggestions - Allow only HTTPS payment links whose normalized host matches an explicit list of approved payment-provider domains. - Reject user-info components, deceptive subdomains, nonstandard schemes, redirects to unapproved origins, malformed internationalized hostnames, and unexpected ports. - Construct payment URLs locally from a trusted base URL and a validated order identifier when possible, rather than displaying an arbitrary downstream URL. - Cryptographically bind the returned order identifier, amount, recipient, and URL through a signed provider response. - Verify the response against the expected payment provider and transaction before displaying it. - Escape the URL and transaction code appropriately for the output channel. - Distinguish order creation from settlement. Use wording such as “Payment order created” until a trusted server-to-server status check confirms successful payment. - Display the verified merchant or recipient and amount next to the link so users can detect inconsistencies. - Avoid hardcoded production-like transaction links in documentation; use an explicitly reserved example domain.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Vague Triggers

Medium

• Confidence: 89% confidence
• Finding: The trigger definition includes broad, colloquial phrases such as "打赏一下" and "送礼物" that can match casual conversation and unintentionally enter a payment-related flow. In a skill that initiates tipping and then hands off to a payment skill, overbroad triggering increases the risk of unintended financial actions despite the later confirmation step.

Vague Triggers

Medium

• Confidence: 90% confidence
• Finding: The trigger section lacks constraints for ambiguous phrases like "刷个礼物" and "送礼物," which may refer to non-payment actions, jokes, or general discussion. Because this skill is specifically designed to create tipping orders and invoke a payment skill, ambiguous activation increases the chance of confusing users into a monetary workflow they did not clearly request.

Static analysis

No suspicious patterns detected.