CVE-2026-33661: Pay SDK Authentication Bypass Vulnerability

CVE-2026-33661 Overview

CVE-2026-33661 is an authentication bypass vulnerability in yansongda/pay, an open-source payment SDK extension package for various Chinese payment services. The vulnerability exists in the verify_wechat_sign() function within src/Functions.php, which unconditionally skips all signature verification when the PSR-7 request reports localhost as the host. This flaw allows attackers to bypass critical RSA signature verification for WeChat Pay callback endpoints.

Critical Impact

This vulnerability enables attackers to forge fake WeChat Pay payment success notifications, potentially causing applications to mark orders as paid without actual payment being received.

Affected Products

• yansongda/pay versions prior to 3.7.20
• Applications using the WeChat Pay callback functionality
• Systems processing WeChat Pay payment notifications

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-33661 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33661

Vulnerability Analysis

The vulnerability is classified under CWE-290 (Authentication Bypass by Spoofing). The core issue lies in a debugging or development convenience feature that was inadvertently left in production code. When the verify_wechat_sign() function receives a request with the host header set to localhost, it completely bypasses the RSA signature verification that normally authenticates WeChat Pay callback notifications. This design flaw allows an attacker to send arbitrary payment notifications that the application will treat as legitimate WeChat Pay confirmations.

Root Cause

The root cause is improper conditional logic in the signature verification function. The code contains an early return statement that exits the verification process when the incoming request's host equals localhost. This was likely intended for local development testing but creates a severe security vulnerability when deployed in production environments, as the Host header is completely controlled by the client making the HTTP request.

Attack Vector

An attacker can exploit this vulnerability by sending a crafted HTTP request to the WeChat Pay callback endpoint with a Host: localhost header. Since the Host header is a client-controlled value, the attacker can easily manipulate it regardless of the actual server's hostname or IP address. This allows the attacker to:

1. Craft a fake payment success notification with arbitrary order and payment details
2. Send the request to the target application's WeChat Pay callback URL
3. Include Host: localhost in the HTTP headers
4. The application will skip signature verification and process the fake notification as legitimate

// Vulnerable code removed in the patch (src/Functions.php)
function verify_wechat_sign(ResponseInterface|ServerRequestInterface $message, array $params): void
{
-    if ($message instanceof ServerRequestInterface && 'localhost' === $message->getUri()->getHost()) {
-        return;
-    }
-
     $wechatSerial = $message->getHeaderLine('Wechatpay-Serial');
     $timestamp = $message->getHeaderLine('Wechatpay-Timestamp');
     $random = $message->getHeaderLine('Wechatpay-Nonce');

Source: GitHub Commit Update

Detection Methods for CVE-2026-33661

Indicators of Compromise

• HTTP requests to WeChat Pay callback endpoints containing Host: localhost header from external IP addresses
• Payment notifications with invalid or missing WeChat Pay signature headers (Wechatpay-Serial, Wechatpay-Timestamp, Wechatpay-Nonce, Wechatpay-Signature)
• Orders marked as paid without corresponding legitimate payment records in WeChat Pay merchant dashboard
• Unusual patterns of successful payment callbacks from non-WeChat IP address ranges

Detection Strategies

• Implement web application firewall (WAF) rules to flag or block requests with Host: localhost from external sources
• Monitor access logs for payment callback endpoints and correlate with expected WeChat Pay notification patterns
• Set up alerts for discrepancies between internal payment records and WeChat Pay merchant portal transactions
• Deploy application-level logging to capture all incoming payment callback requests with full header information

Monitoring Recommendations

• Enable verbose logging on payment callback endpoints to capture complete HTTP headers
• Implement real-time monitoring for financial transaction anomalies and unexpected order status changes
• Cross-reference all successful payment callbacks against WeChat Pay's official transaction query API
• Configure alerts for high volumes of payment callbacks from unusual geographic locations or IP ranges

How to Mitigate CVE-2026-33661

Immediate Actions Required

• Upgrade yansongda/pay to version 3.7.20 or later immediately
• Audit recent payment transactions for any suspicious orders that may have been fraudulently marked as paid
• Implement network-level controls to ensure payment callback endpoints only accept connections from legitimate WeChat Pay IP ranges
• Review and reconcile all payment records against WeChat Pay merchant dashboard

Patch Information

The vulnerability has been fixed in version 3.7.20 of yansongda/pay. The patch removes the conditional bypass that allowed requests with Host: localhost to skip signature verification. Administrators should update their composer dependencies to pull the patched version. For more details, see the GitHub Release v3.7.20 and the GitHub Security Advisory GHSA-q938-ghwv-8gvc.

Workarounds

• If immediate patching is not possible, implement a reverse proxy or WAF rule to reject requests with Host: localhost header on payment callback endpoints
• Deploy IP allowlisting at the network level to restrict WeChat Pay callback endpoints to official WeChat Pay notification IP ranges
• Add application-level validation to reject any callback requests where the Host header does not match expected production domain values

# Example nginx configuration to block localhost Host header
location /wechat/notify {
    if ($http_host = "localhost") {
        return 403;
    }
    # ... rest of configuration
}