Yes, if your WooCommerce store runs the Basel theme's Post Types plugin at version 1.18 or lower with any social login switched on, a stranger can sign in as your admin right now without a password. That's the whole answer. The rest of this post is how to confirm whether that describes your store, and what to do in the next hour if it does.
What happened
On November 11, 2026, a public advisory went out for the Basel Post Types plugin for WordPress. All versions up to and including 1.18 have a coding mistake that makes the plugin fall back to a fixed secret key, and that key sits in the theme's public source code where anyone can read it. With that key, an attacker can fake a social login callback and get signed in as any existing user on the site, admins included, skipping the password and skipping two-factor codes entirely.
It's tracked as CVE-2026-89324 in GitHub advisory GHSA-954p-gvc3-xfxg, with a CVSS score of 9.8. That number is near the top of the scale, and it's deserved. No login required, works from the outside, full account takeover.
Who should care
Three things have to be true at once. You run WordPress with the Basel theme's Post Types plugin. WooCommerce is active. And at least one Basel social login option, Facebook for example, is turned on in your theme settings.
If any one of those is false, this specific attack doesn't work against you. If all three are true, you're exposed today, not someday.
The mechanism, in plain words
The plugin was supposed to check whether WordPress had a proper secret salt set, and use that. A missing pair of quotes in that check made it always fail, so the plugin always used a backup salt that was typed directly into the code. Hardcoded, in developer speak. Shipped to every store, the same value, readable by anyone who downloads the theme.
Secrets only protect you when they're actually secret. Once a signing key is public, anyone can produce a "valid" signature offline, at their desk, with no requests to your server until the final one. The forged request lands on an endpoint that doesn't require being logged in, and the plugin happily hands back a real session cookie for whatever account email the attacker picked.
I've seen the same class of bug in AI-built apps more times than I'd like. A key that was meant to be private ends up in a public bundle. I wrote up the general version in the anon key post and API keys in frontend code. WordPress theme code is just another kind of public bundle. Same failure, different costume.
Check one, is the plugin installed and what version
Log in to your WordPress admin. Click Plugins in the left sidebar. Scan the list for Basel Post Types.
Not there? You can stop reading, this one isn't yours. Though if you use the Basel theme, double check, because the theme usually asks you to install this plugin during setup and it's easy to forget it exists.
If it's there, look at the version number under the plugin name. Version 1.18 or lower means affected. Write that number down. You'll want it when you talk to your developer or when you check for an update.
Check two, is WooCommerce active and is social login on
Same Plugins screen. Find WooCommerce. Does it say Active, or does it offer an Activate link? Active means this check fails, in the sense that the attack precondition is met.
Now the social login part. Open your theme settings, usually under Theme Settings or Basel in the admin sidebar. Look for a login or social section. You're hunting for toggles with names like Facebook, Google, or similar providers. Anything switched on counts.
Safe answer here looks like every provider toggle off, or no social login section configured at all. Unsafe answer is a single provider enabled. One is enough.
If you can't find the setting, don't guess. Ask whoever set up your theme, or ask your developer to grep the site's configuration. "Is any Basel social login provider enabled?" is a one-line question for them.
Check three, if you don't need social login, turn it off now
This is the fastest fix and it's free. The attack only works when at least one social login option is on. Flip them all off and the forged callback has nowhere to land.
Most small stores I've looked at never had meaningful social login usage. Customers type an email and a password, or they check out as a guest. If that's you, switching it off costs nothing and buys you time to do the rest properly. Do it before you finish this post.
If you genuinely rely on Facebook login for returning customers, you have a harder call, and it moves you to the next step.
Check four, update or disable the plugin
Back on the Plugins screen, look for an available update to Basel Post Types. Anything newer than 1.18 is what you want. Install it, then confirm the version number changed.
If no update is showing yet, the honest position is that I don't know when one will ship. The advisory names the problem, not a fixed release. In that gap, ask your developer about deactivating the plugin until a patched version is out. Deactivating may remove some theme features like custom post types for portfolio or team pages, so check what breaks on a staging copy first if you have one. Turning off social login (check three) is the lower-impact move. Deactivating the plugin is the belt and suspenders move.
Old WordPress stores on old PHP are where this kind of thing lingers for months, because nobody wants to touch the update button. If that's your situation, we're running early access on Patch Watch, where a person applies security patches to WordPress stores, including ones still on old PHP.
How to tell whether anything already happened
Hard truth first. A clean login through a forged social callback can look like a normal login in most logs. There's no password failure to flag it. So absence of evidence isn't evidence of absence here.
Still, do the review. Go to Users in your WordPress admin and filter by Administrator. Do you recognize every account? Check the email on each. Look for anything added recently, anything with a slightly off spelling, anything you can't place.
Then check recent activity. WooCommerce stores your orders, so look for refunds, changed payout details, or new coupon codes you didn't create. If you have an activity log plugin, look at logins and settings changes over the last few weeks. Payment gateway settings are the thing I'd check first, because that's where money gets redirected.
If anything looks off, reset every admin password, revoke active sessions (the Users screen has a "Log Out Everywhere" option per user), and rotate your WordPress salts. Then get a developer to go through the database for backdoors. A takeover with admin rights can leave things behind that a password reset won't remove.
What's not known yet
The advisory describes the flaw and the versions affected. It doesn't tell us whether anyone has actually used it against real stores, and it doesn't give a patched version number. I'm not going to invent either. Treat the exposure as real regardless, because the attack needs no special access and the key is public.
What this means for a small business, in general terms
An admin login on a WooCommerce store is the keys to the register. Orders, customer data, payout settings, the ability to install anything. A bug that hands that out to strangers isn't a theoretical risk you file for later. It's the kind of thing that gets found by scanners within days of an advisory going public.
The uncomfortable part is that you didn't write this code and probably never knew the plugin had a login feature. That's normal. Most store owners inherit a stack of plugins from a theme setup and never audit them. The exposure report covers how often that pattern shows up in apps too, and the scan tools comparison covers what automated tooling does and doesn't catch. A hardcoded salt behind a missing pair of quotes is exactly the kind of thing scanners miss and a human reading the code finds.
If you're about to launch a store, or you've got one running and nobody has ever read through what's installed, a Ship Check is one way to get that human read before a stranger does it for you. It's a pre-launch security review, not a hard requirement. The free check above is the first step either way, and you can do it in the next ten minutes.