Security audit

China Payment Integration

Security checks for vulnerabilities and agentic risk

Overview

This is a payment-integration guide, but its callback examples could lead an agent to implement payment confirmation code without enough verification.

Review this skill carefully before installing or using its examples in real payment code. Treat the payment callback snippets as incomplete: require real WeChat signature verification, provider transaction and notification replay checks, amount/currency and merchant/app validation against server-side order records, and atomic idempotent state transitions before any fulfillment or crediting.

A.I.G

Vulnerability Patterns

Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

Location: SKILL.md:94
Finding: WeChat Pay callback headers are collected but never cryptographically verified
Content: View full analysis
{ try { // Step 1: Verify signature const signature = req.headers['wechatpay-signature']; const timestamp = req.headers['wechatpay-timestamp']; const nonce = req.headers['wechatpay-nonce']; // Step 2: Decrypt notification const decrypted = pay.decipher_gcm( req.body.resource.ciphertext, req.body.resource.associated_data, req.body.resource.nonce, ); ``` ### Technical Analysis The handler reads the `Wechatpay-Signature`, `Wechatpay-Timestamp`, and `Wechatpay-Nonce` headers, but it never uses them to verify the HTTP notification signature with the WeChat Pay platform certificate. The comment claiming that signature verification occurs is therefore inaccurate. Authenticated decryption of the `resource` object protects the encrypted resource, but it does not replace verification of the complete callback envelope. The handler also does not enforce timestamp freshness or detect repeated notification identifiers. Applications copied from this example may consequently lack the callback authenticity and replay controls required by the WeChat Pay protocol. Signature verification must use the exact raw HTTP request body. Verifying a parsed and reserialized JSON object can fail because its byte representation may differ from the signed payload. ### Attack Path 1. An attacker captures or otherwise obtains a legitimate callback request sent to the merchant endpoint. 2. The attacker replays the callback, potentially with unverified envelope metadata. 3. The endpoint extracts the signature-related headers but performs no cryptographic verification or timestamp freshness check. 4. If the encrypted resource remains valid, the handler decrypts it and proceeds to payment ...[truncated 549 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Error

Location: SKILL.md:110
Finding: Payment callbacks mark orders as paid without validating amount, currency, or merchant identity
Content: View full analysis
{ // Step 1: Verify signature const isValid = alipay.checkNotifySign(req.body); if (!isValid) return res.send('fail'); // Step 2: Process if (req.body.trade_status === 'TRADE_SUCCESS') { await Order.updateOne( { out_trade_no: req.body.out_trade_no }, { status: 'paid', transaction_id: req.body.trade_no } ); } // Step 3: Acknowledge res.send('success'); }); ``` ### Technical Analysis Cryptographic validation establishes that a notification originated from the payment provider, but it does not establish that the notification matches the merchant's trusted order record. Both examples use only `out_trade_no` and the provider-reported success state before changing the order to `paid`. They do not compare the callback against server-side expectations for: - Paid amount - Currency - Merchant identifier - Application identifier - Payment provider and payment method - Current order owner and status - Previously stored provider transaction identifier For Alipay, relevant callback values commonly include fields such as `total_amount`, `seller_id`, and `app_id`. For WeChat Pay, the decrypted transaction should be checked for the expected merchant/application identifiers and amount details. These values must be compared with immutable server-side order data rather than trusted independently. ...[truncated 1243 chars]
Remediation: View remediation

T09 · Insecure Skill Coding Practices

Warning

Location: SKILL.md:112
Finding: Payment callback updates do not enforce an idempotent order-state transition
Content: View full analysis
Remediation: View remediation

SkillSpector

Vulnerability Patterns

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
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Intent-Code Divergence

High

Category: Not specified by scanner
Confidence: 98% confidence
Finding: The WeChat callback example states that signature verification is performed, but it only reads the signature-related headers and then immediately decrypts and processes the body without actually validating the notification origin. An attacker who can send crafted callback requests could mark arbitrary orders as paid, causing fraudulent fulfillment, accounting corruption, or revenue loss.
Content: No source excerpt is available for this finding.

Intent-Code Divergence

Medium

Category: Not specified by scanner
Confidence: 92% confidence
Finding: Both callback handlers update order state directly without checking whether the order was already processed, despite the skill's own guidance about idempotency. Duplicate or replayed callbacks can trigger repeated side effects such as duplicate fulfillment, repeated downstream event emission, or inconsistent refund/reconciliation behavior.
Content: No source excerpt is available for this finding.