IJPay支付SDK

• Outcome: Review
• Latest audit: May 29, 2026 at 9:32 PM UTC
• Version:
  1.0.0

Overview

This is a documentation-only payment integration skill, but several examples could lead users to implement unsafe payment callbacks or refund controls if copied directly.

Install only as rough reference material, not production-ready payment code. Before using any example, require provider signature verification, merchant/order/amount checks, durable idempotency, authenticated and authorized refund or close operations, protected secrets and certificates, and careful log redaction. Cross-check all flows against the official payment provider and IJPay documentation before deployment.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The early Alipay callback example updates the order state based solely on a reported success status without first performing signature/authenticity verification. In a payment integration skill, this is dangerous because developers may copy the insecure example verbatim, allowing forged callback requests to mark unpaid orders as paid and causing direct financial loss; the later section showing verification does not neutralize the risk because the document presents contradictory guidance.

Intent-Code Divergence

High

• Confidence: 98% confidence
• Finding: The Redis idempotency example is internally inconsistent and unsafe: after setting the key to "processed" for 7 days, the finally block unconditionally deletes the same key, removing the deduplication marker. This allows duplicate callbacks or retries to re-enter business logic after apparent success, which is especially dangerous in payment processing because it can cause repeated settlement, inventory changes, or inconsistent order state.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The callback example states signature verification is already handled, but the shown code directly trusts and parses the request body with no visible verification of WeChat Pay signatures, timestamps, serials, or decrypted resource authenticity. In payment code, this can lead readers to implement a webhook that accepts forged success notifications, enabling fraudulent order completion.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The guide includes highly sensitive configuration fields such as APIv3 key, API key, certificate serial, and private-key path without any explicit warning about secret protection, access control, rotation, or avoiding hardcoding. In a copy-paste integration guide, this omission increases the chance operators will commit credentials to source control, expose them in logs, or deploy them with weak protection.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The certificate-installation section instructs users to download and place certificate materials on the server, including files that contain or accompany private key material, but does not clearly warn that compromise of these files enables impersonation of the merchant in sensitive payment operations. For payment integrations, omission of this warning materially raises the risk of mishandling private keys.

VirusTotal

64/64 vendors flagged this skill as clean.