Picture this: you open Stripe on Monday and find a full refund on a €240 order you didn’t refund. A monthly subscriber has been cancelled too. Your shop’s order notes explain neither.
This is a hypothetical scene, not a reported attack. But it shows what a WPForms flaw, CVE-2026-74991, could do. In versions 1.8.8.2 through 2.0.1.1, someone with the right Stripe payment ID could use a public payment form to trigger a full refund and cancel a subscription. Even if another app took the payment. WPForms fixed it in 2.0.2.
WPForms has more than 5 million active installs. That doesn’t mean all those sites are exposed. Your Stripe setup decides that.
How did a form refund someone else’s payment?
Some card payments need another confirmation, like approving a charge in your banking app. Afterward, the WPForms form is submitted again with a Stripe payment ID attached. It starts with pi_.
On that second submission, WPForms fetched the payment from Stripe and compared its amount with the form total. If they didn’t match, an anti-fraud check refunded the payment in full, marked the reason as fraudulent and, if it was a subscription payment, cancelled the subscription immediately. The visitor saw: “Irregular activity detected. Your submission has been declined and payment refunded.”
The missing check? Ownership. WPForms didn’t verify that the payment ID came from its own form. Someone needed no login to submit a public payment form using a different payment’s ID and a mismatched amount. Payments WPForms had already recorded were skipped by that check, so payments made through other apps on the same Stripe account were the concern.
Version 2.0.2 checks the form ID stored with the Stripe payment first. If it doesn’t belong to that form, WPForms declines the submission instead.
Does your setup put you at risk?
Check WPForms > Settings > Payments: is Stripe connected? Does at least one form have Stripe payments turned on? This code runs only for those payment forms. If WPForms handles only your contact forms, this flaw doesn’t expose your payments.
Update anyway.
The setup I’d check first: a WooCommerce shop taking cards through its Stripe gateway, plus a WPForms deposit or donation form on the same Stripe account. Booking tools, membership plugins, Stripe invoices, Payment Links and separate apps can share it too. Subscriptions hurt most: a monthly course or service customer could be cancelled immediately.
This isn’t a click-and-drain bug. An attacker needs a payment’s Stripe ID, which isn’t normally public. CVE-2026-74991 has a CVSS score of 6.8, or medium, and Patchstack calls it low priority. My take: it moves money, so update today. WPScan plans to publish proof-of-concept details on October 6, 2026, making the attack easier to copy. As of September 29, 2026, there were no public reports of attacks in the wild.
Not sure whether a warning reaches your setup? Try this version and affected-path check.
Update WPForms now
The fix arrived on September 22, 2026; WPScan published its advisory that day too. You could easily miss the changelog line, “Security hardening for the Stripe payment refund process,” among dashboard and AI chat changes.
- Open Plugins > Installed Plugins in WordPress. Find WPForms, whether that’s free WPForms Lite or paid WPForms Pro, and check its version.
- If it’s 1.8.8.2 through 2.0.1.1, update to 2.0.2 or newer. Version 2.0.2.1, released September 23, 2026, is current as of September 29.
- Reload the plugin page. Confirm the number changed, then test a payment form.
- Turn on auto-updates for WPForms or have someone check weekly. Can’t update today? Temporarily turn off Stripe payments on those WPForms forms, or unpublish them until you can.
I wouldn’t depend on catching a quiet fix in a long changelog. A vulnerability scanner can flag a CVE in a plugin you run; WordPress maintenance means someone updates it and checks the form afterward.
Check Stripe for refunds you didn’t make
Start with September 22, 2026, and go further back if you can. Version 1.8.8.2 came out in April 2024, so the useful starting point is whenever you installed an affected version. Stripe moves dashboard labels around; find the closest matching view.
- Payments (Transactions): Filter for Refunded payments. Look for full refunds nobody on your team made, especially ones marked “Fraudulent” on WooCommerce orders, invoices or other payments outside WPForms.
- Subscriptions: Filter for canceled subscriptions. Did one end right after a refund the customer didn’t request?
- Developers (Events / Logs / Workbench): Check refund and subscription-cancel events near those times. Which integration or API request made them: the WPForms connection or your shop’s?
- Radar > Lists: Check the default block lists for real customers’ card fingerprints and emails. Stripe says a refund marked “fraudulent” adds both. Remove customers blocked by mistake.
- WooCommerce: Compare orders with their Stripe payments. A refunded payment beside an order still marked paid or processing is a wierd mismatch to investigate, not proof on its own.
If several WordPress tools take payments, this guide to securing a WordPress shop that takes payments gives wider context. For now, start with refunds.
Found something? Keep the next steps simple
Save dates, payment IDs, amounts and screenshots. Update WPForms first, then compare Stripe events with WPForms form entries from the same times. A suspicious refund alone doesn’t prove this flaw was used.
Tell affected customers plainly what happened. The refund went back to the original card, not to whoever triggered it. Stripe refunds can’t be undone, so send a new payment link if needed. A cancelled Stripe subscription can’t be reactivated; create a new one. Remove affected customers from Radar’s default block lists before asking them to pay again. If you find a pattern tell Stripe support what you’ve found.
One account, several ways to take money
Share one Stripe account across several apps and a weak form can affect payments taken elsewhere. A separate account for every small-shop tool feels like overkill to me. Knowing what’s connected, and removing old connections, is more practical.
Today, check your WPForms version. Then open Stripe’s refunded payments list. Don’t let a “medium” label make that decision for you.