闲鱼全自动砍价助手

• Outcome: Review
• Latest audit: Sep 12, 2026 · 12:11 AM UTC
• Version: 1.0.1

Overview

This skill needs Review because it can automatically send marketplace messages and scheduled follow-ups, while its consent rules and protections against seller-controlled chat content are not clear enough.

Before installing, read the automatic mode carefully. Use it only if you are comfortable with an agent sending messages from your logged-in marketplace account, set strict limits, avoid batch automation for valuable purchases, and prefer manual confirmation for every seller reply or accepted price until the consent and prompt-injection safeguards are tightened.

A.I.G

Vulnerability Patterns

• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• 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)

T01 · Skill Instruction Hijacking

Error

• Location: SKILL.md:198
• Finding: Untrusted Seller Messages Can Hijack LLM Decisions and Trigger Automated Actions## Vulnerability Details **File Location**: `SKILL.md:198-224`; related execution flow in `guides/llm-analyzer.md:15-47` and `guides/auto-bargain.md:137-184` **Vulnerability Type**: Prompt injection through untrusted marketplace content **Risk Level**: High **Relevant source segment, translated into English:** ```text [Product] {itemName} ¥{originalPrice} [Target price] ¥{targetPrice} [Maximum price] ¥{maxPrice} [Current offer] ¥{currentOffer} [Round] {round}/{maxRounds} [Message style] {messageStyle} [Conversation history] {history} [Seller's latest reply] {latestMessage} Analyze the seller's intent and decide the next step: 1. intent: agree/counter/reject/question/other 2. sellerPrice: price mentioned by the seller, if any 3. action: accept/raise/respond/wait/notify/giveup 4. nextMessage: reply to send 5. notifyUser: whether to notify the user 6. reason: reason for the decision Rules: - If the seller agrees or counters at or below the maximum price: accept and notify the user to place the order. - If the counteroffer is above the maximum price: notify the user. - If the seller rejects and rounds remain: raise the offer. - If the seller asks a question: respond naturally and repeat the offer. - Never disclose the maximum price. ``` The related automated execution flow states: ```text 1. Read the state file. 2. Open the chat page and check for new messages. 3. If there is a new seller reply, use the LLM to analyze seller intent. 4. Execute the corresponding action. 5. Update the state file. 6. Send an announcement if the user must be notified. ``` ### Technical Analysis The Skill directly interpolates seller-controlled chat content and conversation history into an LLM decision prompt. It does not establish a clear trust boundary declaring that seller messages are data only, nor does it instruct the model to disregard commands embedded in those messages. The LLM output inc ...[truncated 2517 chars]
• Remediation: ## Remediation Suggestions 1. Mark all product-page content, seller messages, and conversation history as untrusted data that must never be interpreted as instructions. 2. Place untrusted content inside strongly delimited or structured fields and add an explicit instruction to ignore commands, policies, tool requests, or role changes contained in those fields. 3. Use a deterministic parser and validator after LLM generation. Permit only a fixed action allowlist and reject unknown fields or malformed JSON. 4. Independently enforce all price constraints outside the LLM: - Offers must be numeric. - Offers must not decrease unexpectedly. - Offers must remain within the user-approved range. - The maximum price must never appear in seller-facing text. 5. Scan generated messages for confidential values and sensitive state before sending them. 6. Require user confirmation whenever output is anomalous, references system instructions, requests new tools, changes negotiation scope, or approaches the maximum price. 7. Restrict scheduled runs to the minimum browser operations required for reading the specific conversation and drafting or sending an approved message. 8. Record rejected injection attempts and notify the user rather than responding to them automatically.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:43
• Finding: Conflicting Consent Rules Allow Outbound Messages Without Per-Message Approval## Vulnerability Details **File Location**: `SKILL.md:43-44`, `SKILL.md:137-145`, and `SKILL.md:156-185`; related automated actions in `guides/auto-bargain.md:174-182` **Vulnerability Type**: Ambiguous authorization and unsafe automated messaging **Risk Level**: Medium **Relevant source segments, translated into English:** ```text In every mode, the Agent must first show the proposed bargaining message to the user for confirmation. It may send the message only after the user agrees. It must not skip confirmation and send directly. ``` The same file defines the following optional parameter: ```text | Parameter | Required | Description | Example | | Auto-send | Optional | Whether confirmation is unnecessary | true/false | ``` The monitoring workflow further states: ```text Automatic monitoring is disabled by default. After the user explicitly agrees, create a cron job that periodically checks seller replies and sends messages on the user's behalf. ``` The related execution guide directs the Agent to perform these actions: ```text SUCCESS - Notify the user and mark the state successful. ACCEPT - Send an acceptance message, notify the user, and update state. COUNTER - If within the applicable limit, send a higher offer and update state. RESPOND - Generate a response, send it, and update state. GIVE_UP - Send a termination message, notify the user, and update state. FOLLOW_UP - Send a follow-up message and update state. ``` ### Technical Analysis The Skill contains incompatible authorization semantics. One instruction requires confirmation before every message in every mode, while another exposes an `auto-send` option that removes confirmation. The cron workflow also treats consent to enable monitoring as authorization to generate and send subsequent replies. These are distinct permissions: - Permission to inspect a conversation periodically. - Permission t ...[truncated 2299 chars]
• Remediation: ## Remediation Suggestions 1. Replace the ambiguous consent model with explicit, independent modes: - Monitor and notify only. - Monitor and draft responses. - Automatically send non-price informational responses. - Automatically negotiate within a defined price range. 2. Default to monitor-and-notify or draft-only behavior. 3. Require separate, informed consent before enabling any automatic sending. Consent to create a cron job must not implicitly authorize outbound messages. 4. Remove the `auto-send` parameter unless its behavior, scope, expiration, and safeguards are fully specified. 5. Enforce `autoAcceptWithinMax: false` by default in the operational decision flow, not only in documentation. 6. Require fresh confirmation for acceptance messages, price increases, factual representations, commitments, and messages generated after ambiguous seller replies. 7. Store the approved authorization scope in each task state file and have every scheduled run verify it before browser actions. 8. Add maximum reply counts, follow-up delays, expiration times, and an immediate stop mechanism enforced independently of LLM output. 9. Present an audit log containing the seller message, proposed response, action, price change, and authorization basis for every outbound communication.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (17)

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The guide explicitly enables autonomous message sending in a recurring cron task, including acceptance, abandonment, counteroffers, and follow-up messages. That materially exceeds a notification-only boundary and can cause the agent to take transactional actions on the user's behalf without per-message approval, creating integrity, consent, and platform-abuse risks.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The configuration explicitly allows `autoAcceptWithinMax = true`, which means the skill can automatically send an acceptance reply to a seller without per-action user confirmation. That directly conflicts with the skill metadata claim '绝不自动下单，只通知用户' and weakens user control over a transaction-related workflow; in bargaining context, auto-accepting a counteroffer can bind the user to an unintended deal or trigger downstream purchasing steps outside the promised safety boundary.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The trigger phrases are broad, everyday expressions such as asking whether a price is reasonable or how to negotiate, which increases the chance of accidental invocation in ordinary conversation. In a skill capable of initiating browser-driven negotiation workflows and potentially scheduling cron-based follow-up, unintended activation could expose marketplace links, start message drafting, or push the user into an automation flow they did not intend to invoke.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The skill contains contradictory authorization rules: one section requires explicit user confirmation before sending any bargaining message, while another exposes an '自动发送=true' mode that implies messages may be sent without per-message confirmation. In an automation skill that can use browser() and cron() to contact third parties, this ambiguity can lead to unauthorized outbound messaging, user surprise, policy violations, and platform abuse.

Natural-Language Policy Violations

Medium

• Confidence: 97% confidence
• Finding: The document presents all user-facing prompts, confirmations, notification templates, and command phrases exclusively in Chinese, including required reply phrases like "开启", "继续砍", and "停止砍价". This constitutes a natural-language locale constraint without any explicit user choice or justification that the skill is limited to Chinese-speaking users only.

Session Persistence

Medium

• Category: Rogue Agent

Content

### Step 3: 创建状态文件

```bash
mkdir -p ~/.openclaw/workspace/xianyu-bargain-state
```

```json

• Confidence: 84% confidence
• Finding: The guide persists detailed bargaining state to a long-lived local file under a predictable path, including item URLs, seller identifiers, chat URLs, pricing thresholds, and conversation history. Persistent storage of transactional and messaging metadata increases exposure if the local workspace is accessed by other skills, users, or processes, and the guide does not specify retention limits, access controls, or minimization.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The document states manual mode should leave follow-up decisions to the user, but the notification template says a follow-up was already automatically sent. This inconsistency can cause implementers to send messages in situations where the user expected notification-only behavior, undermining consent and increasing the chance of unintended communications.

Natural-Language Policy Violations

Medium

• Confidence: 87% confidence
• Finding: The document is entirely written in Chinese and specifies Chinese invocation phrases such as "批量砍价", "砍价进度", and "停止全部砍价" as the command interface. There is no indication that users may choose another language or that the Chinese-only constraint is optional or region-justified, which can violate language/locale policy requirements.

Natural-Language Policy Violations

Medium

• Confidence: 93% confidence
• Finding: The guide is entirely written to generate and analyze bargaining messages in Chinese, with prescribed Chinese reply styles and examples, but it does not state that the skill is limited to Chinese-language marketplaces or provide user opt-in for locale/language selection. This creates a natural-language policy issue because the skill effectively enforces a specific language behavior by default.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The documented flow automatically types and sends negotiation content to a third-party platform without an explicit warning at the action point that user-provided text will be transmitted externally. This can cause unintended disclosure of personal, sensitive, or strategically important information, especially in an 'automatic bargaining' context where messages may be generated or reused at scale.

Natural-Language Policy Violations

Medium

• Confidence: 91% confidence
• Finding: The file is entirely framed as a Chinese bargaining message template library, and the instruction at L186 directs the LLM to generate replies from these templates. There is no indication that users can opt into another language or locale, and no documented region-specific justification for restricting output to Chinese.

Intent-Code Divergence

Low

• Confidence: 82% confidence
• Finding: L011 的“只通知用户”字面上表示技能只做通知、不代用户执行动作；但 L016 及后续浏览器自动化步骤明确说明技能会直接使用 browser() 和 cron() 自动发送砍价/跟进消息。虽然其“不自动下单”主张未被否定，但“只通知用户”的安全表述与实际会代发消息的行为不一致。

Natural-Language Policy Violations

Low

• Confidence: 92% confidence
• Finding: A language or locale policy violation applies across all file types when a skill forces a specific language without user opt-in. This guide uses only Chinese and does not indicate that the skill is region-specific or offer an alternative language option.

Intent-Code Divergence

Low

• Confidence: 77% confidence
• Finding: The note at L65 says important transactions are recommended for manual confirmation, which frames the automation as limited and user-controlled. However, the guide explicitly instructs automated clicking, typing, and sending of messages in L31-L57, creating a mild contradiction between the safety-oriented note and the actual documented automation behavior.

Natural-Language Policy Violations

Low

• Confidence: 92% confidence
• Finding: This markdown file contains end-user guidance entirely in Chinese and does not indicate that the user can choose another language or that the skill is intentionally limited to a Chinese-speaking context. The policy requires flagging language or locale constraints when they are imposed without user opt-in or clear justification.

Natural-Language Policy Violations

Low

• Confidence: 90% confidence
• Finding: This markdown file presents all operational guidance, warnings, and command mappings exclusively in Chinese. That can violate a language/locale policy when the skill implicitly forces a specific language for all users without documenting an opt-in or region-specific constraint.

Natural-Language Policy Violations

Low

• Confidence: 94% confidence
• Finding: This markdown file presents all headings, instructions, and guidance in Chinese, which can constitute a language/locale policy issue when no user opt-in or justification is provided. The policy specifically calls for flagging skills that force a specific language without offering choice or documenting the constraint.

Static analysis

No suspicious patterns detected.