Security audit

WeChat Pay Integration

Security checks across malware telemetry and agentic risk

Overview

This WeChat Pay helper is a coherent reference skill, but several copyable payment callback and refund examples are unsafe enough to require review before use.

Install only if you will treat it as a reference, not production-ready payment code. Before using any sample with real merchant credentials, replace placeholder/stub verification with official WeChat Pay signature verification, reject invalid callbacks, handle retries idempotently, avoid committing or logging keys, and test payment and refund flows in a controlled non-production environment.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (21)

Intent-Code Divergence

Medium

Confidence: 86% confidence
Finding: The skill gives contradictory security-relevant integration guidance for mini program payments: one section says the payment directory must be configured, while another says no configuration is required. Conflicting instructions in a payment integration skill can cause developers to misconfigure production payment flows, leading to failed payments, insecure workarounds, or bypass of required platform controls.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The Express example documents a Native payment order creation flow but calls `nativePay.preay(...)`, which is a non-existent method rather than the implemented `prepay(...)`. In a payment integration skill, this is security-relevant because it can break order creation, cause developers to ship nonfunctional payment code, and encourage unsafe ad-hoc fixes around payment handling and error processing.

Intent-Code Divergence

High

Confidence: 99% confidence
Finding: This is a real vulnerability: the primary callback-handling example claims signature verification is required, but its verifySignature implementation always returns true and therefore accepts forged payment or refund notifications. In a payment integration skill, this is especially dangerous because developers are likely to copy the first complete example into production, allowing attackers to spoof successful payments, refunds, or state changes without a valid WeChat Pay signature.

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: The Express sample contradicts its own comment and WeChat Pay refund semantics: it generates a new outRefundNo on every request using Date.now(), which breaks idempotent retry behavior. If a client retries after a timeout, network error, or uncertain response, the server may create multiple distinct refund requests for the same order, leading to duplicate or unintended refunds and reconciliation issues.

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: The refund callback exception path always returns a success response even when signature verification, parsing, or decryption fails. This causes the payment platform to stop retrying a failed or unverified notification, which can silently drop legitimate refund events and leave local refund state inconsistent with upstream payment state.

Intent-Code Divergence

High

Confidence: 99% confidence
Finding: The refund callback handler explicitly notes that signature verification should occur, but then proceeds to decrypt and process the notification without authenticating that it actually came from WeChat Pay. In a payment-refund workflow, this can let an attacker forge or replay callback payloads and drive local refund/order state changes, creating financial loss and accounting inconsistencies.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: The decryption example appears incorrect for WeChat Pay callback handling because it base64-decodes the nonce, while the documented callback nonce is typically used as a plain string/bytes value. Developers copying this code may fail to decrypt valid notifications, causing callback processing failures, payment state desynchronization, and possible operational denial of service in payment confirmation flows.

Intent-Code Divergence

Medium

Confidence: 91% confidence
Finding: The document gives contradictory guidance about when to return HTTP 200 versus when business processing is complete. In a payment callback context, this can lead implementers either to acknowledge the callback before durable validation and state updates, risking lost or inconsistent payment records, or to delay acknowledgment and trigger repeated retries and duplicate-processing races.

Intent-Code Divergence

Low

Confidence: 94% confidence
Finding: The document incorrectly states that signature verification should 'use the WeChat Pay public key to decrypt the signature' and compare the result with a SHA256 digest. In RSA signature verification, implementations should use a standard verify operation rather than describe or encourage raw 'public-key decryption,' because this can mislead developers into building nonstandard or incorrect verification logic that may accept forged or malformed signatures.

Intent-Code Divergence

Medium

Confidence: 98% confidence
Finding: The combine-payment callback example decrypts and processes notification data without first verifying the callback signature, even though the surrounding document explicitly states that signature verification is mandatory. In payment integrations, this can cause developers to accept forged notifications and mark sub-orders as paid, enabling order-state tampering, fraud, and downstream business logic abuse.

Vague Triggers

Medium

Confidence: 81% confidence
Finding: The trigger guidance is very broad and encourages direct invocation for many payment, code, and troubleshooting requests without meaningful exclusion criteria or safety gates. In a payment integration context, over-broad triggering can cause the skill to engage in sensitive guidance or surface risky sample code inappropriately, increasing the chance of misuse, misconfiguration, or reliance on AI-generated payment logic.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The example initializes payment configuration with merchant ID, certificate serial number, API v3 key, and a private signing key read from disk, but it provides no warning that these values are highly sensitive secrets that must never be hardcoded, committed, logged, or shared with clients. In a payment-integration skill, this omission is risky because developers may copy the example directly into production-like code and mishandle credentials, enabling fraudulent request signing or broader payment compromise if secrets leak.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The documentation walks through creating real APP payment orders and returning signed invocation parameters to the mobile app without warning that this hits live payment APIs and can trigger real financial transactions. In the context of a WeChat Pay integration skill, the lack of sandbox/test-use cautions increases the chance that developers will run copied examples against production credentials, causing unintended charges, financial loss, or accidental merchant-side transaction creation during testing.

Missing User Warnings

Medium

Confidence: 87% confidence
Finding: The example loads a merchant private key from disk and performs real payment API operations without clearly warning about secure credential storage, secret rotation, least-privilege file permissions, and the sensitivity of payment/order data. In a payment skill context, omission of those warnings is more dangerous because readers are likely to copy the example directly into production-like environments, increasing the risk of key exposure or mishandling of regulated financial data.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The file provides ready-to-run code that creates and closes WeChat Pay orders against the live production API endpoint, but it does not prominently warn users that executing the example will perform real external payment operations and may change real order state. In a payment-integration skill, this omission is dangerous because developers may copy and run the sample with real credentials in development or testing, causing unintended transaction attempts, order closures, or confusion during incident response.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The sample embeds private key and API v3 key values directly in code-shaped configuration without an explicit warning or secure-loading pattern. In a developer-facing payment integration skill, this is risky because users often copy examples verbatim into repositories or deployments, leading to credential exposure and compromise of payment operations.

Missing User Warnings

Medium

Confidence: 86% confidence
Finding: The sample shows sensitive material such as the merchant private key and API v3 key embedded directly in configuration, without prominently warning against hardcoding or insecure storage. In real integrations, developers often copy such patterns into production, increasing the risk of credential leakage via source control, logs, backups, or shared examples.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The example embeds realistic credential fields such as merchant ID, app ID, APIv3 key, serial number, and reads a private key directly from a local PEM file, but provides no warning about secret handling. In a payment-integration skill, developers may copy this pattern into source code, hardcode real secrets, commit them to repositories, or mishandle key files, leading to credential exposure and payment-system compromise.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The example embeds sensitive payment configuration values directly in code, including merchant ID, certificate serial number, private key material, app ID, and API v3 key, without any warning that these must be protected. In a payment-integration skill, readers may copy this pattern into production code or source control, leading to credential leakage, unauthorized payment operations, or compromise of merchant payment infrastructure.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The documentation provides Python and Node.js configuration examples that embed `private_key` and `api_v3_key` directly in source files without any warning against hardcoding or committing secrets to version control. In a payment-integration skill, readers are likely to copy these snippets verbatim, which can lead to credential leakage, unauthorized API use, forged requests, and compromise of merchant payment operations if the codebase or logs are exposed.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: This demo script prints the full request body, nonce, timestamp, and complete signature input string to stdout. In a payment integration context, those logs can expose transaction metadata and identifiers in CI logs, terminals, or shared environments, increasing the risk of information disclosure and making replay/debug artifacts easier to misuse.

VirusTotal

66/66 vendors flagged this skill as clean.

View on VirusTotal

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Node.js/APP支付/APP支付.md:25

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Node.js/JSAPI支付/JSAPI支付.md:22

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Node.js/Native支付/Native支付.md:16

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Node.js/回调处理/回调处理.md:17

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Node.js/小程序支付/小程序支付.md:25

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Node.js/退款/退款.md:16

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Python/APP支付/APP支付.md:45

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Python/JSAPI支付/JSAPI支付.md:46

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Python/Native支付/Native支付.md:45

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Python/小程序支付/小程序支付.md:45

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/代码示例/Python/退款/退款.md:44

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: references/商户模式/签名与验签/签名与验签规则.md:47

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: scripts/Node.js/signature_demo.js:16

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: scripts/Python/signature_demo.py:55