批处理专家

• Outcome: Review
• Latest audit: Sep 16, 2026 · 10:18 AM UTC
• Version: 1.0.0

Overview

The skill is a coherent batch-processing guide, but its core example for preventing duplicate work is unsafe enough to warrant careful review before use.

Review and adapt the examples before installing or using this skill for real batch jobs. Do not copy the Redis idempotency snippet for financial, email, account, or other irreversible operations; use atomic reservation, durable completion records, database unique constraints, downstream idempotency keys, or transactional outbox/inbox patterns instead.

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 (1)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:227

Finding

Non-Atomic Idempotency Check Permits Duplicate Side Effects

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 227–234
Vulnerability Type: Check-then-act race condition and incomplete crash-safe idempotency
Risk Level: High

python

def process_with_idempotency(item, redis_client):
    key = f"idem:{item['id']}"
    # Check whether the item has already been processed
    if redis_client.exists(key):
        return {"status": "skipped", "reason": "already_processed"}
    # Process the item
    result = do_process(item)
    # Mark it as processed with a TTL
    redis_client.setex(key, 86400, "1")  # 24-hour TTL
    return result

Technical Analysis

The example implements idempotency as three independent operations:

1. Check whether the Redis key exists.
2. Execute do_process(item).
3. Store the completion key.

This is a check-then-act race condition. Two concurrent workers processing the same item can both observe that the key does not exist and then both execute do_process(item). The later setex calls do not undo duplicate side effects.

The design is also unsafe under process failure. If a worker successfully performs the side effect but crashes before setex, no completion marker is recorded. A resumed job or retry will consequently execute the operation again.

The fixed 24-hour TTL introduces another duplication window: the same item can be processed again after the key expires, even when the underlying business operation must remain permanently idempotent.

Attack Path

1. An attacker or ordinary input source submits records with the same item['id'], or causes the same item to be assigned to multiple concurrent workers.
2. Worker A calls redis_client.exists(key) and receives false.
3. Before Worker A writes the marker, Worker B checks the same key and also receives false.
4. Both workers invoke do_process(item).
5. Both workers perform the associated side effect, such as charging an order, sending a message, or ...[truncated 1043 chars]

Remediation

View remediation

Remediation Suggestions

• Atomically reserve each idempotency key before processing by using Redis SET key token NX EX ttl. A worker must not proceed unless it successfully acquires the reservation.
• Store an unguessable per-worker token as the value and use a Lua script or transaction when changing or releasing the reservation, ensuring that one worker cannot modify another worker's reservation.
• Model explicit states such as processing, completed, and failed. Carefully define recovery behavior for expired processing reservations.
• Pass the same durable idempotency key to downstream services that support native idempotency controls.
• For database-backed side effects, write the idempotency record and business mutation in one transaction with a unique constraint on the idempotency key.
• When the side effect and state store cannot participate in one transaction, use a transactional outbox or inbox pattern with a deduplicating consumer.
• Retain completion records for at least as long as duplicate execution would remain harmful. Do not use a 24-hour TTL for operations requiring permanent deduplication.
• Add concurrency tests in which multiple workers process the same identifier simultaneously, as well as fault-injection tests that terminate a worker between the side effect and completion-state update.

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)

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The display name, summary, description, triggers, and operational guidance are all presented in Chinese, which effectively forces a specific language for users. The file does not offer an opt-in language choice or explain that the skill is intentionally limited to a Chinese-speaking context.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 89% confidence

Finding

The trigger list contains broad generic terms such as '批量', '并行', and '进度' that are common in many unrelated tasks. In an agent environment, this can cause unintended activation of a skill that includes exec-capable guidance, leading the agent to apply batch-processing behaviors or run scripts in contexts the user did not intend.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.