# Security Brief: CVE-2026-16947 WooCommerce Payment Plugin Flaw Enables Payment Bypass and Credential Theft

Canonical: https://vulnify.app/blog/security-brief-cve-2026-16947-woocommerce-payment-bypass-credential-theft

CVE-2026-16947 is a critical unauthenticated vulnerability in the Total Processing Card Payments for WooCommerce plugin through version 7.3. Attackers can abuse server-side request forgery to redirect payment verification requests, expose payment-gateway credentials, and potentially mark arbitrary WooCommerce orders as paid.

What happened CVE-2026-16947 is a critical vulnerability affecting the Total Processing Card Payments for WooCommerce WordPress plugin through version 7.3. The flaw occurs in the plugin's server-side payment verification process. According to the vulnerability record coordinated by WPScan, the plugin accepts a user-controlled path when constructing a verification request without sufficiently validating where that request will be sent. It also fails to authenticate the response before using it to determine whether a WooCommerce payment succeeded. Together, these weaknesses create a serious attack path. An unauthenticated attacker can potentially cause the WordPress server to send a payment-verification request to an attacker-controlled host rather than the legitimate payment service. Because the outgoing request can contain the merchant's payment-gateway credentials, those credentials may be disclosed to the attacker. The attacker-controlled system can then return a forged response indicating that a transaction was successful, potentially causing WooCommerce to mark an order as paid even though no legitimate payment was completed. WPScan classifies the vulnerability as server-side request forgery, or SSRF, under CWE-918 and assigns a CVSS 3.1 score of 9.1, rated Critical. The associated vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N . This reflects an attack that can be performed remotely, requires low attack complexity, requires no authentication, and does not require interaction from another user. The primary consequences are high confidentiality and integrity impact rather than service availability. The vulnerability was publicly disclosed by WPScan in late August 2026 and credits researchers Pablo González Pérez, Francisco José Ramírez Vicente, and Iñigo Sánchez Enciso. At the time of this brief, WPScan lists no known fixed version. The WordPress.org plugin directory also states that the plugin was closed on August 10, 2026 and is currently unavailable for download pending a full review. WordPress.org lists version 7.3 as the latest version available before the closure. How the vulnerability works Payment plugins typically communicate with an external payment gateway to confirm whether a transaction has actually completed. That verification process is an important trust boundary. A website should only send sensitive authentication information to approved payment infrastructure, and it should only trust payment results that can be linked to the legitimate gateway and expected transaction. In a simplified secure workflow, the merchant site communicates with a predetermined payment endpoint: WooCommerce store | | Payment verification request v Approved payment gateway | | Verified transaction response v WooCommerce order marked as paid CVE-2026-16947 breaks that trust model because part of the destination used for verification can be influenced by an unauthenticated user. If that input causes the server-side request to reach another host, the application server effectively becomes the component making the attacker-directed request. This is the defining characteristic of SSRF. The second weakness is equally important. The plugin does not sufficiently establish the authenticity of the response before treating it as authoritative payment information. As a result, redirecting the request is not limited to information disclosure. An attacker-controlled server may also be able to provide a response that looks like a successful payment verification. This combination is considerably more serious than a conventional open redirect. The victim's browser is not simply being sent somewhere unexpected. The merchant's own WordPress server performs the request, potentially attaches credentials intended for the payment gateway, receives the response, and then uses that response when changing an order's payment state. Why SSRF matters here SSRF vulnerabilities allow external users to influence requests originating from an application server. Depending on implementation, SSRF can sometimes be used to reach internal services, cloud metadata endpoints, administrative systems, or external hosts that would not normally receive sensitive server-side requests. CVE-2026-16947 has a particularly clear impact because the vulnerability description specifically identifies payment-gateway credential disclosure. Credentials carried by a server-side payment request are substantially more sensitive than ordinary public website information. Their precise capabilities depend on the gateway configuration, so website owners should not assume that disclosure only affects the single WooCommerce transaction involved in an attack. Any exposed payment credentials should be treated as compromised until their permissions and potential use have been investigated. The vulnerability also has a direct commercial impact. If a forged response can cause an arbitrary WooCommerce order to transition into a paid state, an attacker may be able to obtain products or services without completing the corresponding payment. Automated fulfilment can make this particularly problematic because digital downloads, licence keys, account upgrades, bookings, subscriptions, or fulfilment workflows may begin as soon as WooCommerce considers payment complete. Why it matters for website owners For WooCommerce operators, this issue affects the integrity of the payment process itself. Many vulnerabilities primarily expose technical information or create an indirect route toward further compromise. CVE-2026-16947 potentially interferes directly with whether an order is considered paid, while also exposing credentials used by the merchant's payment integration. The lack of an authentication requirement significantly increases the importance of identifying affected installations. An attacker does not need a WordPress administrator account, customer account, or shop-manager account according to the published vulnerability classification. The attack is network-accessible and requires no user interaction, which is why the assigned CVSS score is high. Stores selling immediately deliverable products deserve particular attention. If payment completion triggers automated processes, a fraudulent status change can propagate quickly. Examples include sending downloadable products, issuing software licences, creating prepaid balances, activating subscriptions, provisioning accounts, or sending orders directly to fulfilment systems. Physical-goods merchants are also exposed, although fulfilment processes may create additional opportunities to catch suspicious orders before goods leave the business. Reviewing gateway records independently of WooCommerce can help identify orders that WordPress considers paid even though the processor has no matching transaction. Affected versions and current fix status The published CVE record identifies Total Processing Card Payments for WooCommerce versions up to and including 7.3 as affected. WPScan currently lists the plugin as having no known fix for CVE-2026-16947. Administrators should therefore not assume that simply reinstalling version 7.3 or downloading another copy resolves the vulnerability. WordPress.org currently reports that the plugin was closed on August 10, 2026 and is unavailable for download while a full review is pending. The directory identifies version 7.3 as the latest listed release. A repository closure is not itself proof that a particular vulnerability caused the closure, so those two facts should not be conflated. It does, however, mean administrators cannot currently rely on the normal WordPress.org update channel to obtain a confirmed patched release. Because no fixed version is listed by the vulnerability coordinator at the time of writing, organizations still using the plugin should monitor the vendor, WordPress.org, WPScan, and the CVE record for updated remediation information. Until a corrected release is available and verified, disabling the affected payment integration is the safer approach where operationally possible. What to check on your site Identify the plugin immediately. Check whether totalprocessing-card-payments or the Total Processing Card Payments for WooCommerce integration is installed on production, staging, development, or archived WordPress environments. Confirm the installed version. Versions through 7.3 are covered by the published affected range. Do not rely only on whether WordPress reports an available update. Check whether the plugin is active. An installed but disabled plugin is different from one currently handling checkout traffic. Remove unnecessary vulnerable components rather than leaving them dormant indefinitely. Review recent WooCommerce orders. Look for orders recorded as paid without a matching transaction in the authoritative payment-gateway dashboard or settlement records. Review gateway credentials. Because credential disclosure is part of the documented vulnerability impact, consider exposed credentials potentially compromised and follow the payment provider's procedures for rotation or replacement. Inspect application and server logs. Look for unusual payment-verification requests, unexpected destination hosts, abnormal callback activity, unexplained order-state changes, and verification failures. Check automated fulfilment. Determine what happens immediately after an order becomes paid and whether fraudulent status changes could have triggered downloads, licence issuance, subscription activation, shipping, credits, or other business processes. Review copies of the site. Development and staging environments may contain real gateway credentials or cloned production configuration even when they do not process genuine purchases. Immediate mitigation Where the affected plugin is active and no confirmed patched version is available, administrators should strongly consider disabling the integration and using an alternative supported payment method until the issue has been remediated. The appropriate operational response will depend on the store, but continuing to process payments through a component with a published unauthenticated payment-bypass vulnerability creates a difficult risk to justify. Payment-gateway credentials associated with an affected installation should be reviewed and, where appropriate, rotated. Rotation is particularly important if logs show suspicious outbound verification traffic or if the affected site was publicly reachable while the vulnerable plugin was active. Revoking an old credential is preferable to simply generating another credential while leaving the previous one valid. Merchants should also reconcile WooCommerce's order records against the payment processor's own transaction records. WooCommerce should not be treated as the sole source of truth during an incident involving forged payment verification. Orders with no corresponding processor transaction should be investigated before fulfilment continues. Network-level outbound controls can provide additional defence by limiting which external services a web server can contact. Allowlisting approved payment infrastructure can reduce the impact of some SSRF scenarios, although outbound filtering should be treated as defence in depth rather than a replacement for correcting the vulnerable application logic. What secure payment verification should do A payment integration should not allow an unauthenticated request to freely determine where server-side payment verification is sent. Verification endpoints should be fixed or selected from a strict allowlist of expected gateway destinations. URL construction should reject attempts to substitute hosts, protocols, or other components that change the intended destination. Responses should also be authenticated or independently validated according to the payment provider's supported protocol. A successful HTTP response is not evidence that a payment occurred. The application should validate the transaction identity, expected merchant account, amount, currency, order association, and any cryptographic authentication or signature provided by the payment platform. A simplified secure design looks more like this: Customer checkout | v WooCommerce order | | Verification to fixed/approved gateway only v Payment provider | | Authenticated transaction result v Validate order + amount + transaction | v Mark order as paid These controls matter beyond this single CVE. Payment callbacks, webhooks, return URLs, API endpoints, and verification routines all cross trust boundaries and should be designed under the assumption that client-supplied values can be manipulated. Using Vulnify for follow-up checks Vulnify can help website owners identify the public WordPress stack surrounding an affected installation. The Stack Checker can support an external review of WordPress components and exposed technology information. This is useful when confirming what is publicly detectable or when reviewing several WordPress properties for potentially outdated components. The Chain Checker and Redirect Checker can also help examine public redirect behavior around checkout and payment-related URLs. These tools address related public-surface risks, but CVE-2026-16947 is fundamentally a server-side payment-verification vulnerability. A normal redirect check cannot confirm that gateway credentials are safe or prove that the vulnerable plugin logic is no longer present. Remediation therefore still requires direct WordPress administration, plugin inventory review, payment-gateway investigation, and transaction reconciliation. Public-surface testing is most useful as part of the follow-up process rather than as a substitute for those actions. Related reading Security Hardening Checklist Redirect Prevention Guide Article 32 for Web Teams: Technical Measures Explained The WordPress hardening checklist is the most directly relevant follow-up because payment plugins operate inside the broader WordPress and WooCommerce environment. Keeping plugins inventoried, supported, updated, and removed when no longer required reduces the window in which vulnerabilities can remain unnoticed. Conclusion CVE-2026-16947 combines two security failures at a particularly sensitive point in the WooCommerce transaction process. An attacker can potentially influence where the server sends a payment-verification request and the plugin can then trust a response without adequately establishing that it came from the legitimate payment infrastructure. The published consequences include disclosure of merchant payment-gateway credentials and forged successful payments. The issue affects Total Processing Card Payments for WooCommerce through version 7.3 and is remotely exploitable without authentication or user interaction according to its published CVSS assessment. With no known fixed version currently listed by WPScan and the plugin closed in the WordPress.org directory pending review, affected merchants should prioritize identification, containment, credential review, and transaction reconciliation. For ecommerce operators, the most important validation is not simply whether WordPress reports an order as paid. Payment status should reconcile with the payment provider's authoritative transaction records. Any unexplained difference between the two deserves immediate investigation. Sources National Vulnerability Database: CVE-2026-16947 : Total Processing Card Payments for WooCommerce <= 7.3