WooCommerce payment plugins accept forged payment notices

Q: How do I check that the secret key for payment notices is filled in?

Open the module's settings under WooCommerce > Settings > Payments and find the secret key field, which each provider names differently. The value comes from your account with the provider. In several of the vulnerable plugins, such as Walletdoc, Asaas and Cardinity, the key is empty by default, and the empty field is exactly what lets the attack through.

# TagsSecurityWooCommerce

The WPhost team19 Oct 20269 min read

Between 14 and 19 October 2026 the NVD, the US National Vulnerability Database, published records for more than ten WordPress payment plugins, most of them for WooCommerce, with one flaw in common. The plugin accepts a forged notice that the payment went through and marks the order as paid, although nothing was paid. The attacker needs no account on the store. WPScan filed all the records, and most score between 5.3 and 6.5 on the CVSS scale ("medium"). CISA, in the records it has reviewed, notes no evidence of attacks.

No Bulgarian provider is among them. BORICA, ePay.bg, myPOS and the Econt and Speedy plugins are not in the records. Any payment module can have the same flaw, though, including one written for a single store, so the check below applies to every store taking payments online.

How a store learns that an order is paid

The customer enters card details on the bank's or payment provider's page, not on the store. After the payment, the provider sends the store a notice (a webhook) that the money has arrived, or sends the customer back with the result in the address. The payment plugin reads it and moves the order to Processing, which in WooCommerce means paid. The customer gets a confirmation, stock goes down and the order joins the shipping queue.

A genuine notice is signed with a secret key known only to the provider and the store, and the plugin has to check the signature before trusting it. According to the CVE records, the key is empty by default in Walletdoc, Asaas and Cardinity, and in Visma Pay it stays empty until the merchant enters their credentials. With an empty key the plugin accepts a notice from anyone. In Sifalo Pay one genuine transaction number is enough. The attacker pays for an order of their own and uses that payment's number to mark other pending orders as paid.

What the store stands to lose

The attacker places an order, "pays" with the forged notice and waits for the goods. If parcels go out with Econt or Speedy as soon as an order is marked paid, nobody notices until someone looks for the money in the bank account. With digital products such as courses or ebooks, access to the file is granted at once, so the loss is immediate.

WPForms Lite, a form plugin with more than 5 million active installations according to wordpress.org, has a similar flaw. Before version 2.0.2.2, its PayPal Commerce payment forms accept a submission with no payment made. The visitor sees the confirmation and you get the usual email, while PayPal has neither an order nor a payment.

Is your store affected?

Some of the affected plugins are below. If yours is listed and older than the version shown, your site is affected.

Plugin	Fixed in version
Walletdoc Payment Gateway for WooCommerce	1.8.5
Asaas Gateway for WooCommerce	2.7.8
Visma Pay for WooCommerce	1.2.2
Cardinity Payment Gateway for WooCommerce	3.4.2
Rede Itaú for WooCommerce	5.5.3
Snap Finance	3.12.0
Gateway for Vantiv on WC	no fix
WPForms Lite	2.0.2.2

You can see the payment plugins and their versions in Plugins > Installed Plugins, or list them all with the command below in cPanel's Terminal. The WP-CLI guide explains how to work with WP-CLI.

Bash

# cPanel > Terminal, in the site's folder
# Read-only. Lists the plugins related to payments.
wp plugin list --fields=name,title,status,version \
  | grep -iE "pay|gateway|forms"

What to do

Update the payment plugin to the latest version. If yours has no fix, as with Gateway for Vantiv on WC, deactivate it and offer customers another way to pay until a fix comes out.
Open the module's settings under WooCommerce > Settings > Payments and check that the secret key for notices is filled in. Each provider names it differently, and the value comes from your account with the provider. In several of the vulnerable plugins, the empty field is what let the attack through.
Before you ship an order paid online, check that the money shows up with the provider or in your bank account, and never skip this for unusual orders (a large amount, many units, a new customer).

Check the paid orders of the last few weeks the same way. Filter WooCommerce > Orders by the Processing status, or run the command below, which also shows the transaction number the payment plugin recorded.

Bash

# cPanel > Terminal, in the site's folder
# Read-only. Orders in Processing status since 1 October.
wp wc shop_order list --user=ADMIN_LOGIN \
  --status=processing --after=2026-10-01T00:00:00 \
  --fields=id,total,payment_method_title,transaction_id,date_paid

Replace ADMIN_LOGIN with an administrator's username and the date with the start of the period to check. Look up each transaction_id in your provider account. If a payment is not there, hold the order until you know what happened.

What we do

With vulnerability (CVE) monitoring we match the plugins, theme and WordPress on your site against the vulnerability (CVE) databases every day, the payment module included. As soon as a vulnerability appears in something you use, we send you an alert, and we try the update on a copy in staging first. Your site can be hosted anywhere. If you would like us to add your store, write to us through the inquiry form.

Frequently asked questions

What is the problem with forged payment notices in WooCommerce?

Between 14 and 19 October 2026 the NVD published records for more than ten WordPress payment plugins, most of them for WooCommerce, with one flaw in common. The plugin accepts a forged notice that the payment went through and marks the order as paid, although nothing was paid. The attacker needs no account on the store.

Are BORICA, ePay.bg and myPOS affected?

No Bulgarian provider is in the records, and BORICA, ePay.bg, myPOS and the Econt and Speedy plugins are not among them. Any payment module can have the same flaw, though, including one written for a single store, so the check applies to every store that takes payments online.

How does a store know an order has been paid?

The customer enters card details on the bank's or provider's page, and after the payment the provider sends the store a notice (a webhook) or returns the customer with the result in the address. The payment plugin reads it and moves the order to Processing, which in WooCommerce means paid. A genuine notice is signed with a secret key known only to the provider and the store, and the plugin has to check the signature before trusting it.

Which payment plugins are affected and which versions fix them?

The affected plugins include Walletdoc (fixed in 1.8.5), Asaas (2.7.8), Visma Pay (1.2.2), Cardinity (3.4.2), Rede Itaú (5.5.3) and Snap Finance (3.12.0). Gateway for Vantiv on WC has no fix. WPForms Lite has a similar flaw in its PayPal Commerce payment forms, fixed in version 2.0.2.2.

What does a store lose to a forged payment?

How do I check that the secret key for payment notices is filled in?

Open the module's settings under WooCommerce > Settings > Payments and find the secret key field, which each provider names differently. The value comes from your account with the provider. In several of the vulnerable plugins, such as Walletdoc, Asaas and Cardinity, the key is empty by default, and the empty field is exactly what lets the attack through.

How do I check that an order paid online was really paid?

Before you ship an order paid online, check that the money shows up with the provider or in your bank account, above all for unusual orders with a large amount, many units or a new customer. Review the paid orders of the last few weeks the same way by filtering WooCommerce > Orders by the Processing status. Look up each transaction number in your provider account and hold the order if the payment is not there.

What if my payment plugin has no fix?

Deactivate it and offer customers another way to pay until a fix comes out, as with Gateway for Vantiv on WC. If the module was written for your store, ask the developer how it checks the provider's notices and what happens when the secret key is missing, because a notice without a valid signature should be rejected.

Sources