T05 · Unauthorized Access and Privilege Escalation
- Location
references/gotchas.md:278- Finding
Unauthenticated Forced-Refund Action Enables Unauthorized Financial Operations
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent WeChat Pay integration guide, but its recovery instructions include a client-triggered forced-refund path without adequate authorization or normal checks.
Review carefully before installing or using. Do not copy the force_refund pattern into a public Mini Program path as written; refunds should require explicit admin/operator authorization, verified order ownership or eligibility, idempotency, audit logging, a short-lived feature flag or backend-only job, and confirmed sandbox/production environment selection.
references/gotchas.md:278Unauthenticated Forced-Refund Action Enables Unauthorized Financial Operations
The comment states the force_refund action does not require a user auth token, which conflicts with the surrounding payment guidance and encourages implementers to omit authentication on a refund-capable path. Even if WeChat cloud-call context exists, that is not a substitute for application-layer authorization; without explicit authZ checks, any caller who can reach the function may attempt refunds against arbitrary order IDs.
The skill gives operational guidance for live payment creation, refunds, and order-state changes without an explicit warning that these actions can affect real money and production records. In a payments context, omission of safety boundaries increases the chance that an agent or developer executes refund or order-management steps against live systems during debugging or review workflows.
The backfill/debugging section includes querying live orders and introducing a temporary force-refund path, but it does not clearly warn that refunds are financially irreversible and could impact real customer orders if misused. In this context, a force-refund mechanism lowers normal business-logic safeguards, so insufficient caution materially raises the risk of accidental or unauthorized refunds.
The documented temporary force_refund flow exposes a server-side capability to trigger refunds directly from a client-initiated path and explicitly bypasses normal status checks. In a payment context, any refund primitive that is callable without strict authorization, ownership validation, idempotency controls, and audit checks can be abused to issue unauthorized refunds or probe order records.
The sample explicitly recommends bypassing normal status checks to invoke refunds as a gradual workaround for historical failures. In a financial workflow, normal checks are the control boundary preventing duplicate, premature, or unauthorized refunds, so documenting their bypass materially increases the chance that developers deploy unsafe recovery code into production.
This markdown file is entirely written in Chinese and does not indicate that language selection is optional or limited to a justified region-specific audience. Under the stated policy, forcing a specific language without user opt-in can be a natural-language policy violation.