Imagine waking up to discover that every subscription renewal on your membership site has silently failed overnight — not because of a bank issue or a Stripe outage, but because someone with a free account on your own website flipped an invisible switch and walked away.
Who's at Risk — and How Bad Is It?
Paid Memberships Pro is one of the most widely deployed membership and subscription plugins in the WordPress ecosystem, active on over 100,000 websites worldwide. Those sites span fitness studios selling monthly workout plans, indie media outlets running reader-supported journalism, online course creators, nonprofits managing donor memberships, and software companies gating premium content. In short: if a site uses WordPress to charge recurring fees and relies on Stripe to process them, there's a real chance it's running this plugin.
The vulnerability, tracked as CVE-2026-4100, carries a CVSS score of 7.1 (HIGH). No active exploitation has been confirmed yet — but security researchers warn that "not yet" can turn into "actively abused" very quickly once a flaw is publicly documented. The window to patch is open right now, but it won't stay open forever.
What's Actually Happening — No Jargon Required
To understand the attack, you need to understand one concept: a webhook. Think of it as a notification hotline between two services. When Stripe processes a payment, cancels a subscription, or flags a failed charge, it immediately calls your website back on this private line to say "hey, here's what just happened." Your site listens, then takes the appropriate action — upgrading an account, suspending access, sending a receipt. The entire payment lifecycle depends on this line staying open and properly configured.
The flaw in Paid Memberships Pro means that virtually anyone who has an account on your website — even a free subscriber who signed up just to read one blog post — can reach behind the curtain and tamper with that notification hotline. They can delete it entirely, cutting off all payment communications. They can create a new, misconfigured one that sends events to the wrong place. Or they can "rebuild" it in a way that breaks the synchronization between Stripe and your site. None of this requires technical skill. It requires only that the attacker be logged in.
The practical damage is severe and insidious. Subscription renewals stop being processed. Cancellations from Stripe's side go unacknowledged, meaning cancelled customers keep accessing paid content. Failed payment retries go unnoticed. Site owners often won't catch the problem immediately — payment failures can look like normal churn at first glance, and by the time the pattern is obvious, days or weeks of revenue disruption may have already occurred. A disgruntled former member, a competitor, or simply a malicious actor scanning for vulnerable sites could trigger this with a few clicks.
The Technical Detail That Matters
For security professionals and plugin developers reading this: the root cause is missing capability checks on three AJAX action handlers — specifically wp_ajax_pmpro_stripe_create_webhook, wp_ajax_pmpro_stripe_delete_webhook, and wp_ajax_pmpro_stripe_rebuild_webhook. WordPress's AJAX system correctly requires authentication to reach these handlers, which is why the attack requires a logged-in user. But it performs zero verification of what that user is actually permitted to do. Any role — Subscriber on up — passes right through. This is a textbook broken access control / missing authorization vulnerability (CWE-862), not a sophisticated exploit chain. That's precisely what makes it dangerous at scale: no special knowledge required, just a valid session cookie.
Discovery, Exploitation Status, and Known Campaigns
The vulnerability was discovered and responsibly disclosed through Wordfence's coordinated disclosure program, which has become one of the primary clearinghouses for WordPress plugin security research. As of publication, no active exploitation in the wild has been confirmed, and there are no known threat actor campaigns targeting this specific CVE. The plugin's developers have issued a patch, which is available in version 3.6.6 and later.
That said, the security community's standard guidance applies here with extra urgency: vulnerabilities affecting payment infrastructure attract financially motivated attackers faster than almost any other category. The barrier to exploitation is extremely low — no special tools, no malware, no elevated access needed. Expect opportunistic scanning to begin shortly now that the CVE is public.
What You Need to Do Right Now
If you run a WordPress site with Paid Memberships Pro installed, take these three steps today — in this order:
- Update Paid Memberships Pro to version 3.6.6 or higher immediately. Log into your WordPress dashboard, navigate to Plugins → Installed Plugins, find Paid Memberships Pro, and click Update. If you use a managed host (WP Engine, Kinsta, Pantheon), trigger the update from your host's dashboard or staging environment and push to production. Do not wait for your next scheduled maintenance window. Version 3.6.5 and everything before it is vulnerable.
- Audit your Stripe webhook configuration right now. Log into your Stripe Dashboard, go to Developers → Webhooks, and verify that the endpoint URL listed matches your actual website and that it was last updated around or before today's date. If you see unexpected endpoints, unfamiliar URLs, or a "last updated" timestamp you don't recognize, treat your webhook configuration as compromised. Delete unknown endpoints and use the plugin's rebuilt webhook tool — after patching — to regenerate a clean one.
- Review your recent membership and payment logs for anomalies. Check both your WordPress membership logs (under Memberships → Orders in the Paid Memberships Pro admin panel) and your Stripe Dashboard event logs for any unexpected gaps in webhook delivery, a spike in unacknowledged events, or accounts that should have been downgraded but weren't. If you find inconsistencies, cross-reference with your subscriber list to identify any accounts that may have had unauthorized access to paid content during the exposure window.
The Bigger Picture
This vulnerability is a sharp reminder of a pattern that keeps repeating in the WordPress plugin ecosystem: payment-critical functionality gets bolted onto a platform originally designed for blogging, and the authorization model doesn't always keep pace with the stakes. When the worst outcome of a broken access control bug was that a subscriber could see a draft post, the consequences were manageable. When the same class of bug sits between a business and its revenue stream, the calculus changes completely.
Patch. Verify. Audit. In that order, and before the weekend.