If your WordPress store runs the Security For WooCommerce plugin at version 1.0.10 through 1.0.16, yes, you're at risk, and the flaw is about as bad as a plugin bug gets. On November 5, 2026, GitHub published advisory GHSA-vh3v-vj4j-59pc (CVE-2026-100109) describing a bug that lets any visitor, logged in or not, create a new user account on your site and choose that account's role. Pick "administrator" and you own the store. It carries a CVSS score of 9.8 out of 10, which is the scale security teams use to rank how severe a flaw is, and 9.8 sits near the top.
If you don't have that plugin, or you have it at a version outside that range, this specific bug doesn't touch you. The checks below take maybe ten minutes either way.
What actually broke
The plugin exposes an action that creates WordPress users. In plain words, there's a door on your site that accepts "make me a new account" requests. That door was supposed to check two things before doing anything. First, is the person asking allowed to create users at all? That's called a capability check. Second, should the person asking get to pick what role the new account has?
The advisory says the plugin "does not perform capability checks when creating users through an action available to unauthenticated visitors, and lets the caller choose the new account's role." Both checks are missing. Anyone on the internet can walk up, ask for an account, ask for it to be an administrator, and get one. No password guessing. No phishing. Just a request to a URL your site already answers.
I've reviewed a lot of apps before launch, mostly AI-built ones on Lovable, Bolt and Replit, and this is the same family of mistake I see constantly. The code that does a sensitive thing trusts that whoever reached it was already vetted. Nobody vetted them. On Supabase apps it shows up as a missing RLS policy. On WordPress it shows up as a missing capability check. Same hole, different framework.
Who should care
Owners of WordPress or WooCommerce sites with Security For WooCommerce installed at version 1.0.10 through 1.0.16. That's the whole list from the advisory. It doesn't matter what theme you run, who hosts you, or whether your store is busy or quiet. An attacker doesn't need to know anything about you. They need a list of sites with the plugin and a script.
If you're not sure whether you even have it, that's the first check.
Check one, find the plugin and its version
Log in to your WordPress dashboard. In the left menu, click Plugins, then Installed Plugins. Scroll or use the search box at the top right and type "Security For WooCommerce."
A safe answer is that it isn't there at all, or it's there and the version number under the plugin name is something other than 1.0.10 through 1.0.16. An unsafe answer is any version from 1.0.10 to 1.0.16, active or not. Deactivated plugins can still have their files on disk, and whether a deactivated copy of this specific plugin still answers that user-creation request isn't something the advisory spells out. Treat it as live until someone who can read the code tells you otherwise.
If you don't have dashboard access, whoever built or maintains your store does. Send them this post and ask for the version number.
Check two, deactivate it if you're in range
Found a version in the affected range? Deactivate the plugin right now, from the same Plugins screen, using the Deactivate link under its name. Then leave it off until you've confirmed a fixed version exists and installed it.
Here's what's not known yet. The advisory lists the affected versions. It doesn't tell me, as of writing, which version closes the hole or whether one has shipped. So I'm not going to guess a number. Check the plugin's page in the WordPress plugin directory or the advisory itself for an update before you turn it back on.
Yes, turning off a plugin called "Security For WooCommerce" feels backwards. Do it anyway. The plugin is the hole.
Check three, look for admin accounts you didn't create
This is the one that tells you whether anything already happened. Click Users in the left menu. Near the top of the list you'll see links like All, Administrator, Editor, Customer. Click Administrator.
A safe answer is a short list of names you recognize, every one of them a real person on your team. An unsafe answer is any account you can't place. Look closely at usernames and email addresses, because an attacker who wants to stay hidden will pick names that look boring. Something resembling a vendor, a support account, or a generic word. If you can't say who it is and when it was added, assume it's bad.
Sort by the Registered or Posts column if your admin shows one. Anything new since the start of November deserves a hard look.
Check four, remove unknown admins and reset every real one
Found a stranger? Hover over the account, click Delete, and when WordPress asks what to do with their content, attribute it to a real admin so you don't lose posts or orders tied to that account. Then go further.
Change the password on every legitimate administrator account. All of them. An attacker with admin access could have changed a real admin's password or email, or left themselves a way back in, so you can't trust that your own accounts are still only yours. If you use two-factor authentication, confirm it's still turned on for each admin and that the recovery codes haven't been regenerated.
While you're there, check the admin email under Settings, General. An attacker who swaps that address can reset passwords at will.
Check five, have a developer look for what changed
Deleting the account doesn't undo what the account did. An administrator can install plugins, edit theme files, add scripts to your checkout page, change the PayPal or Stripe account that receives your money, and create more admin accounts with different names. Ask your developer to go through the Plugins list for anything unfamiliar, compare theme and plugin files against clean copies, review recent edits to pages and posts, and confirm your payment gateway settings still point at you.
If you don't have a developer on call, this is the kind of job I built Patch Watch for. It's early access, a person applying security patches to WordPress stores, including ones stuck on old PHP that can't just click Update. It's one option. A competent WordPress freelancer can do this too.
What this means for a small store
Admin takeover of an ecommerce site is a different animal from a defaced blog. The person who gets in has access to your customer list, your order history, and the settings that decide where payments go. They can inject a card-skimming script into checkout and nobody notices for months because the store keeps working. They can turn your domain into a spam relay and get your email blacklisted.
None of that is confirmed to have happened to anyone from this bug. I want to be plain about that. The advisory describes what's possible, not a list of victims, and I don't have one either. But "possible" with a 9.8 severity score and zero login required is the kind of possible you act on today, not next sprint.
How this fits the bigger pattern
I keep a running tally of what I find when I review apps before they launch. The exposure report covers the AI-built side, and the common thread is identical to this plugin bug. Something sensitive is reachable without the check that was supposed to guard it. Sometimes it's an anon key with no row-level policy behind it. Sometimes it's an API key sitting in the frontend bundle. Here it's a user-creation endpoint with no capability check.
Automated scanners catch some of this and miss plenty. I compared the current crop in this roundup if you want to see where they fall down.
If you're about to launch something, WordPress or otherwise, and you'd rather have a human walk the trust boundaries before a stranger does, a Ship Check is a pre-launch security review where I do exactly that. One option among several. The five checks above cost nothing and you can run them before lunch.