ClawHub
Back to skill

Security audit

云开发-微信支付

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent payment/refund guidance, but it includes unsafe temporary refund instructions that could let refunds be triggered without adequate authorization controls.

Review carefully before installing or using this skill. Its normal payment/refund advice is relevant, but do not copy the force_refund flow as written into production. Any refund recovery tool should be admin-only, server-authorized, idempotent, audited, eligibility-checked, rate-limited, and removed or disabled after the backfill is complete.

SkillSpector

Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (3)

Context-Inappropriate Capability

Medium
Confidence
92% confidence
Finding
The skill explicitly recommends adding a temporary `force_refund` action that bypasses normal status checks, which weakens a core business-control boundary around money movement. Even if intended for backfill or recovery, such guidance can lead implementers to expose an authorization-sensitive refund path that may be invoked outside the intended workflow, enabling unauthorized or duplicate refunds if not strictly gated and removed.

Context-Inappropriate Capability

Medium
Confidence
92% confidence
Finding
The documented temporary `force_refund` action bypasses normal status checks and directly triggers refunds based on an order ID, creating a privileged recovery path that can be abused if exposed to ordinary mini-program users or insufficiently authorized operators. In a payment skill, this is especially dangerous because it normalizes adding an emergency refund endpoint in production without showing strict server-side authorization, audit logging, idempotency, or compensating controls.

Intent-Code Divergence

High
Confidence
89% confidence
Finding
The comment stating the `force_refund` action does not need a user auth token encourages implementers to omit authentication or confuse WeChat cloud-call context with application-level authorization. Even if platform context exists, lack of explicit user/admin authorization on a refund-capable action can let unauthorized users trigger financial operations, and the contradictory guidance increases the chance of insecure implementation.

Static analysis

No suspicious patterns detected.