CVE-2024-11205: WPForms Flaw Let Any Subscriber Refund Your Stripe Payments (6 Million Sites, CVSS 8.5)

Most WordPress vulnerabilities we cover end in a hijacked admin account or a web shell on the server. CVE-2024-11205 is different, and in some ways more insidious: it does not take over your site — it takes your money. A missing authorization flaw in WPForms, the form builder plugin active on more than 6,000,000 WordPress websites, allowed any logged-in user — even a lowly subscriber — to issue arbitrary Stripe refunds and cancel Stripe subscriptions on the site owner’s account.

For any site that collects payments through WPForms, that is a direct line into the revenue stream. The flaw was disclosed in December 2024, prompted a high-severity alert from India’s CERT-In, and had public proof-of-concept code available shortly afterward. If you use WPForms with Stripe, here is what happened and how to make sure you are patched.

CVE Details at a Glance

• CVE ID: CVE-2024-11205
• Plugin: WPForms — Easy Form Builder for WordPress (Contact Forms, Payment Forms, Surveys & More)
• Vulnerability type: Missing Authorization (CWE-862) leading to unauthorized payment refunds and subscription cancellations
• CVSS Score: 8.5 (High), as assigned by Wordfence. NVD later scored it 6.5 (Medium) with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
• Affected versions: 1.8.4 through 1.9.2.1
• Patched version: 1.9.2.2, released 18 November 2024
• Privileges required: Authenticated, Subscriber-level access or above
• Precondition: The site uses the WPForms Stripe integration to take payments
• Reported by: the researcher “villu164” via the Wordfence Bug Bounty Program
• Active installations: 6,000,000+

How the Vulnerability Works

To understand this bug, it helps to know the two questions a WordPress plugin should ask before performing any sensitive action:

• “Is this request genuine?” — answered by checking a nonce, a one-time token that proves the request came from a real page on your site and not a forged one elsewhere. This defends against cross-site request forgery.
• “Is this user allowed to do this?” — answered by a capability check, typically current_user_can(), which confirms the user’s role actually permits the action.

These are two entirely separate questions, and this is precisely where WPForms slipped. Its Stripe integration exposed two AJAX handlers — ajax_single_payment_refund() and ajax_single_payment_cancel() — which perform exactly what their names suggest: refund a payment, and cancel a subscription. These are administrator-only operations by any reasonable standard.

But instead of a capability check, the plugin gated these handlers behind a function called wpforms_is_admin_ajax(). Despite the reassuring name, that function does not verify that the user is an admin. It only verifies that the request arrived through WordPress’s admin-ajax endpoint — which, importantly, every logged-in user on the site can reach, regardless of role. It answers “did this request come through the admin AJAX path?”, not “is this person an administrator?”

The handlers were still protected by nonce verification, so a naive forged request would fail. But a nonce is an authenticity check, not an authorization check. An attacker who holds a legitimate account on the site is a legitimate visitor — they can simply obtain a valid nonce and then send the refund or cancellation request with it. The nonce says “yes, this is a real request from a real logged-in user,” the plugin never asks whether that user is allowed to refund anything, and the action goes through.

The exploitation barrier, then, is simply having any account at all. On sites with open registration — membership sites, WooCommerce stores, communities, course platforms, comment systems requiring registration — an attacker just signs up. Subscriber is the default role for new registrations and is normally the least trusted role in WordPress, with no ability to publish, edit, or configure anything. Here, it was enough to reach into the site’s Stripe account.

Real-World Impact

This is a financial vulnerability rather than a site-takeover one, and it is genuinely damaging in ways that are easy to underestimate:

• Direct revenue loss. An attacker could refund payments back to the original payers — including their own prior purchases, effectively giving themselves free products or services while keeping whatever they bought.
• Mass, scripted damage. Because the action is a simple AJAX request, an attacker could automate it and refund large volumes of transactions in bulk, potentially draining a merchant’s Stripe balance.
• Subscription churn inflicted from outside. Cancelling recurring subscriptions destroys predictable revenue and forces businesses to re-acquire customers who never chose to leave.
• Accounting and reconciliation chaos. Phantom refunds corrupt financial records, confuse bookkeeping, and can trigger payment-processor scrutiny of the merchant account.
• Customer trust damage. Customers receiving unexplained refunds or cancellation notices for services they still want will reasonably question whether the business is competent or compromised.

Worryingly, reporting at the time of disclosure estimated that roughly half of WPForms installations — on the order of three million sites — were still running a vulnerable version, though only those using the Stripe integration for payments were actually exposed to financial harm.

How to Check If You Are Affected

• Confirm the plugin and version. In your dashboard, go to Plugins > Installed Plugins and find WPForms (or WPForms Lite). The version is shown beneath the plugin name. Anything from 1.8.4 up to and including 1.9.2.1 is vulnerable; 1.9.2.2 or later is patched.
• Check whether you use Stripe. Go to WPForms > Settings > Payments and see whether a Stripe account is connected. If you do not take payments through WPForms, the financial risk does not apply to you — but you should still update.
• Check whether user registration is open. Under Settings > General, if “Anyone can register” is enabled, the pool of potential attackers is anyone on the internet. If registration is closed, the risk is limited to your existing users.
• Audit your Stripe activity. If you were running a vulnerable version with Stripe connected, log into your Stripe dashboard and review the refund and subscription-cancellation history for the exposure window. Look for refunds and cancellations that you or your team did not initiate.

How to Fix It

The remediation is simple, and the vendor handled disclosure responsibly.

• Update WPForms to 1.9.2.2 or later. Go to Plugins > Installed Plugins, apply the available update, and confirm the version afterward. The patch replaces the flawed check with a proper capability check so only genuinely authorized users can refund or cancel.
• Enable automatic updates for WPForms and other payment-adjacent plugins so security patches land without waiting on a manual review cycle.
• Review and tighten user registration. If your site does not need open registration, disable it. If it does, understand that every subscriber is a potential attacker surface and keep plugins current accordingly.
• Apply least privilege to roles. Audit which roles exist on your site and what capabilities they hold. Remove unused accounts, and never grant elevated roles casually.
• Monitor your payment processor independently. Enable Stripe email notifications for refunds and cancellations so that unauthorized financial activity surfaces immediately rather than at month-end.

Takeaway

CVE-2024-11205 is a textbook demonstration that authentication is not authorization. Knowing who a user is tells you nothing about what they are permitted to do, and a nonce check — however correctly implemented — can never answer that second question. Missing authorization is one of the most common vulnerability classes in the WordPress ecosystem precisely because it is so easy for a developer to assume that a function named “is admin something” is doing more than it actually is.

For site owners, the practical lesson is that the humble subscriber account deserves more respect than it usually gets. Every logged-in user, no matter how low their role, is standing inside your walls. That makes prompt patching, closed or carefully managed registration, and least-privilege role design not optional extras but core parts of running a WordPress site that handles money. Update your plugins, watch your payment dashboard, and assume that anything reachable by a logged-in user will eventually be probed by one.