Description

The UPI QR Code Payment Gateway WordPress plugin through 1.4.3 does not verify that a payment-confirmation request actually belongs to the order and customer it claims to confirm, allowing unauthenticated attackers to mark an arbitrary order as paid without making any payment.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-05T06:16:59.180Z",
  "pubdate": "2026-10-05T06:16:59.180Z",
  "executiveSummary": "The UPI QR Code Payment Gateway WordPress plugin, version 1.4.3 and earlier, contains a critical authentication bypass vulnerability in its payment confirmation mechanism. This vulnerability arises from an improper validation of transaction integrity, specifically failing to confirm that a payment-confirmation request cryptographically or logically belongs to the transaction and customer specified.\nThe vulnerability allows an unauthenticated remote attacker to manipulate the payment status of any order within the e-commerce system. By submitting a crafted request to the plugin's endpoint, an attacker can arbitrarily mark orders as 'paid' without performing the actual financial transaction. This bypasses the payment gateway's intended logic and results in unauthorized fulfillment of goods or services. The risk is severe as it leads to direct financial loss and the potential for large-scale fraudulent activity without requiring any administrative privileges or complex exploit conditions.",
  "technicalDetails": "The vulnerability originates from a flaw in the request validation logic within the UPI QR Code Payment Gateway plugin. The plugin exposes an endpoint intended to receive asynchronous or synchronous callbacks from the payment gateway to finalize order statuses. However, the plugin fails to implement sufficient verification checks—such as validating order-specific tokens, digital signatures, or session-bound data—to ensure that the incoming confirmation request is legitimate and associated with a valid, pending transaction initiated by a legitimate customer.\nThe root cause is the reliance on insecurely verified inputs for state-changing operations. Specifically, the plugin does not cross-reference the payment confirmation request against a unique, non-predictable identifier or a server-side order state object before updating the order status to 'paid' in the WordPress database.\nThe attack flow proceeds as follows: 1) The attacker identifies a target order ID through typical e-commerce storefront interactions or public-facing order status pages. 2) The attacker crafts a request mimicking the structure of the plugin’s expected payment callback. 3) The attacker submits this request directly to the vulnerable plugin endpoint. 4) The plugin processes the request and, lacking authentication or validation of the request's origin, updates the database entry for the target order ID to reflect a 'Paid' status. 5) The e-commerce backend triggers order fulfillment processes based on this forged success notification.\nBecause this operation does not require prior authentication or elevated privileges, the attack surface is exposed to any remote user capable of interacting with the WordPress site's exposed API endpoints. The lack of cryptographic nonces or HMAC-based request validation means the system effectively trusts all external input to its payment callback handler. The post-exploitation impact is significant, as it enables systematic inventory theft and service exploitation by bypasssing the payment flow entirely, rendering the integrated payment gateway ineffective."
}