xianyu-automation-skill

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:43 AM UTC
• Version: 1.0.2

Overview

This skill is meant to automate a Xianyu store, but it asks users to trust account-changing automation while its advertised safety limits and success reporting are not actually enforced in the included code.

Review carefully before installing. Use only a dedicated low-permission Xianyu key, keep dry-run or manual approval at the dependency layer, avoid unattended production use, and do not rely on the advertised daily caps, batch caps, or refresh success messages until they are actually enforced and tested.

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: __init__.py:7

Finding

Documented automation safety limits are not enforced

Content

View full analysis

Vulnerability Details

File Location: __init__.py:7-8, __init__.py:16-28, __init__.py:31-68, __init__.py:72-83; contradictory security claims at SKILL.md:204-220
Vulnerability Type: Missing quota and batch-limit enforcement
Risk Level: High

Vulnerable Code

python

# Automation safety limits
MAX_DAILY_PRODUCTS = 20  # Max products created per day
MAX_BATCH_REFRESH = 100  # Max products refreshed per batch

class XianYuAutomation:
    """闲鱼自动化运营管理器"""
    
    def __init__(self, api_client: Optional[XianYuAPIClient] = None):
        """
        初始化自动化管理器
        
        Args:
            api_client: API客户端实例
        """
        self.api_client = api_client or XianYuAPIClient()
        self.product_manager = XianYuProductManager(self.api_client)
        self._daily_count = 0
        
        # 默认配置
        self.config = {
            'refresh_interval_days': 3,  # 商品刷新间隔（天）
            'max_daily_products': MAX_DAILY_PRODUCTS,  # 每日最大商品数量
            'price_adjustment_range': 0.1  # 价格调整范围（±10%）
        }
    
    def refresh_product_activity(self, product_ids: List[str]) -> List[Dict[str, Any]]:
        """
        刷新商品活跃度（通过重新编辑商品信息）
        
        Args:
            product_ids: 商品ID列表
            
        Returns:
            刷新结果列表
        """
        results = []
        for product_id in product_ids:
            try:
                detail_result = self.api_client.get_product_detail(product_id)
                if detail_result.get('code') != 200:
                    results.append({
                        'product_id': product_id,
                        'success': False,
                        'error': 'Failed to get product detail'
                    })
                    continue
                
                results.append({
                    'product_id': product_id,
                    'success': True,
                    'message': 'Product activity refreshed (placeholder)'
                })
        
...[truncated 3404 chars]

Remediation

View remediation

Remediation Suggestions

1. Reject refresh requests whose length exceeds the configured limit before making any API calls:

python

if len(product_ids) > MAX_BATCH_REFRESH:
    raise ValueError(
        f"Batch contains {len(product_ids)} products; "
        f"maximum allowed is {MAX_BATCH_REFRESH}"
    )

2. Determine the number of products a matrix operation could create and reject the operation if it would exceed the remaining daily quota.
3. Increment the quota only for successful creations and account explicitly for partial batch failures.
4. Store the daily count together with its date in durable, concurrency-safe storage. Reset it only when the applicable calendar day changes.
5. Use an atomic reservation or transaction before issuing batch operations so concurrent workers cannot each pass the same quota check.
6. Prevent callers from increasing safety limits beyond a trusted administrative maximum.
7. Preserve explicit user confirmation or dry-run behavior at the final mutation boundary rather than relying solely on wrapper-level checks.
8. Add automated tests covering oversized refresh batches, repeated creation calls, partial failures, concurrent calls, process restarts, and day rollover.
9. Correct SKILL.md until the controls are actually implemented so it does not describe unenforced limits as code-enforced.

T09 · Insecure Skill Coding Practices

Warning

• Location: __init__.py:42

Finding

Product refresh reports success without performing an update

Content

View full analysis

Vulnerability Details

File Location: __init__.py:42-61
Vulnerability Type: False success reporting and fail-open operation status
Risk Level: Medium

Vulnerable Code

python

for product_id in product_ids:
    try:
        # 获取商品详情
        detail_result = self.api_client.get_product_detail(product_id)
        if detail_result.get('code') != 200:
            results.append({
                'product_id': product_id,
                'success': False,
                'error': 'Failed to get product detail'
            })
            continue
        
        # TODO: 这里需要实现商品更新接口
        # 目前闲鱼管家API文档只提供了创建和详情接口
        # 需要确认是否有商品更新接口
        
        results.append({
            'product_id': product_id,
            'success': True,
            'message': 'Product activity refreshed (placeholder)'
        })
        
    except Exception as e:
        results.append({
            'product_id': product_id,
            'success': False,
            'error': str(e)
        })

Technical Analysis

The method is named refresh_product_activity() and returns a successful refresh result, but its only external action is a read-only product-detail request. The comments explicitly acknowledge that the update operation has not been implemented.

A successful detail lookup is therefore incorrectly treated as proof of a successful mutation. This violates fail-safe status reporting: an unimplemented or unverified state-changing operation must not return success. Downstream schedulers, dashboards, and decision engines can no longer distinguish a completed refresh from a placeholder response.

Attack Path

1. A caller supplies a valid product ID to refresh_product_activity().
2. get_product_detail() returns a response whose code equals 200.
3. No product update, edit, or refresh API is invoked.
4. The method nevertheless returns success: True and the message Product activity refreshed (placeholder).
5. A scheduler or mon ...[truncated 1041 chars]

Remediation

View remediation

Remediation Suggestions

1. Until a real update API is available, fail closed and return an explicit unsupported-operation result:

python

results.append({
    'product_id': product_id,
    'success': False,
    'error': 'Product activity refresh is not implemented'
})

2. If an update API is implemented, return success only after receiving and validating an authoritative mutation response.
3. Where possible, retrieve the product after mutation and verify an expected version, update timestamp, or changed field.
4. Separate read validation from mutation status by using distinct fields such as detail_retrieved, update_attempted, and update_confirmed.
5. Remove placeholder success messages from production paths.
6. Add tests asserting that a successful detail lookup alone can never produce a successful refresh result.
7. Emit structured logs and metrics for unsupported, attempted, failed, and verified operations so monitoring cannot confuse them.

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• 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

Findings (2)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 93% confidence

Finding

The skill materially overstates its safety and capability boundaries, claiming enterprise-grade autonomous operations, confirmation safeguards, and intelligent decisioning without evidence those controls are actually implemented. In a high-impact automation context, this mismatch can cause operators or downstream agents to trust destructive actions, enable broader permissions, or skip independent validation, which creates real security and operational risk.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium

• Category: Excessive Agency
• Confidence: 88% confidence

Finding

The documentation explicitly permits automation workflows to bypass interactive confirmation by using _unsafe methods, which weakens a primary control on write operations. In a store-management skill that can create listings, delete products, and modify order prices, confirmation bypass significantly increases the blast radius of prompt injection, logic bugs, or misconfiguration, especially when marketed as unattended automation.

Content

Scanner excerpt · SKILL.md (reported line 212)May include surrounding context.

md

### Write Operation Confirmation

By default, all product mutations flow through the safe `client.create_product()` / `client.delete_product()` / `client.modify_order_price()` path, which requires interactive user confirmation. Automation workflows that need to skip confirmation must explicitly use the `_unsafe` variants.

### Unsafe Methods (Tightly Controlled Automation)

Static analysis

No suspicious patterns detected.