CVE-2026-103299 in Payment Gateway Plugin
Summary
by MITRE • 10/26/2026
The Payment Gateway WordPress plugin through 2.2.0 does not ensure a shared secret is configured before using it to authenticate the bank's payment-notification callback, allowing unauthenticated attackers to forge a valid notification and mark any WooCommerce order as paid on installs where the secret has not been set, and the same callback lets them move any pending order to a failed state whether or not the secret is configured.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in Payment Gateway WordPress plugin versions up to 2.2.0 represents a critical failure in authentication logic for handling payment notifications from external banking systems. This flaw stems from an improper implementation of shared secret verification, which is intended to ensure that incoming callbacks originate from the legitimate financial institution rather than malicious actors. In secure architectures, webhooks or callback endpoints must validate signatures or tokens provided by the sender before processing any state changes in the application database. However, this plugin fails to enforce a mandatory check for a configured shared secret prior to accepting and acting upon these notifications. This oversight creates a significant attack surface where unauthenticated attackers can interact directly with the payment notification endpoint without possessing valid credentials or cryptographic keys.
The technical mechanism of exploitation involves crafting forged HTTP requests that mimic legitimate bank responses. Because the application does not verify the presence or correctness of the shared secret, it accepts any incoming payload as authentic if it matches the expected structural format for a success response. Consequently, an attacker can send a specially crafted request to mark any WooCommerce order in the system as paid without actually making a payment. This allows fraudsters to obtain goods or services by artificially inflating their transaction status within the e-commerce platform's database. The impact is direct financial loss and potential reputational damage for merchants relying on this plugin, as inventory may be released and orders fulfilled based on false premises of completed transactions.
Furthermore, the vulnerability extends beyond just marking orders as paid; it also allows attackers to manipulate order statuses into a failed state regardless of whether the shared secret is configured or not. This aspect of the flaw suggests that certain code paths within the callback handler do not perform adequate authorization checks for status updates leading to failure states either. By forcing pending orders into a failed state, an attacker can disrupt legitimate business operations, potentially causing inventory discrepancies, customer service issues, and loss of sales revenue. The ability to toggle order statuses arbitrarily undermines the integrity of the transaction lifecycle managed by WooCommerce, allowing for both fraudulent gains through fake payments and operational disruption through forced failures.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to properly verify the identity of users or services attempting to access resources. It also relates closely to CWE-345 Insufficient Verification of Data Authenticity, since the application accepts data from an external source without validating its origin. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior corresponds to techniques involving T1078 Valid Accounts or more broadly T1190 Exploit Public-Facing Application, where attackers leverage misconfigured services to gain unauthorized access or modify system state. The lack of input validation and authentication checks on a public-facing endpoint makes it an attractive target for automated scanning tools and opportunistic attacks targeting WordPress ecosystems.
Mitigation strategies must prioritize immediate remediation through software updates if available from the vendor. For installations where no patch is immediately provided, administrators should implement network-level controls such as IP whitelisting to restrict access to the payment callback URL only to known banking server addresses. Additionally, implementing a reverse proxy with WAF rules can help filter out malformed requests or those lacking specific headers required by legitimate banks. It is also critical for developers and site owners to ensure that all sensitive configuration values, including shared secrets, are strictly enforced in code logic before any state-changing operations occur. Regular security audits of plugin codebases should include reviews of webhook handlers to verify that authentication checks are robust and applied consistently across all status modification endpoints.