WooCommerce Social Login: anyone can log in as admin
Your WordPress patches itself. The plugin with the 9.8 severity score does not — it came from a marketplace, so it has no way of telling your site that a fix exists. The fix has existed since 27 July.
What happened. The Social Login plugin for WordPress and WooCommerce, in every version up to and including 2.8.7, accepts an Apple identity token without checking its signature. Anyone who knows an administrator's email address can be logged in as that administrator. Severity: 9.8 out of 10.
Who can skip this. If your site is not WordPress, or you have never installed a social login plugin, this does not apply. Five minutes of checking will confirm it.
Why it is worth your time. Because the fix shipped on 27 July, five days before the public advisory, and a great many shops never received it. It is a paid marketplace plugin, and those do not appear in WordPress's automatic updates.
- Exactly which plugin it is, and where to look to know whether you have it.
- Why your WordPress core patches itself and this piece does not.
- What to check if the plugin was there: updating is not the end of it.
- What the public WordPress.org registry says about the free alternatives — queried today.
There is a quiet assumption behind most WordPress security advice, and it is wrong often enough to matter: that updates find their way to your site on their own. For the WordPress core, they do. For a plugin you bought once on a marketplace, there is no channel at all — nothing on your site knows where to ask whether a newer version exists.
That is the entire story of CVE-2026-8457. The severity is 9.8 out of 10, the fix has been available since 27 July, and thousands of shops are still running the version without it — not through neglect, but because nothing told them.
We do managed hosting and website and application development, so we read these advisories for a living. We covered a similar one on 22 July, when the wp2shell alarm woke up half the WordPress world. This one is quieter, and in one way worse: there is nothing to discover and nothing to wait for. The patch is ten days old. It just has to reach your site.
Your WordPress updates itself. This does not.
WordPress has a good automatic update mechanism. It works for the pieces listed in the public WordPress.org registry: your site checks that registry periodically, sees a newer version and either installs it or flags it.
A plugin bought on a marketplace is not in that registry. There is nowhere for your site to ask.
We checked rather than assumed. On 7 August we queried the public WordPress.org registry API for the plugin's slug. The answer was {"error":"Plugin not found."}. It does not exist there.
| Part of your site | Updates itself? | What has to be true |
|---|---|---|
| The WordPress core | Yes, by default | Nothing. Security releases install on their own unless someone disabled them |
| Plugins from the WordPress.org registry | Yes, if you switch it on | One toggle per plugin on the Plugins screen, or your hosting panel |
| Plugins bought on a marketplace | Almost never | An updater supplied by the author plus the purchase code entered on your site — otherwise you download and upload it by hand |
| Custom themes and plugins | No | Whoever wrote them. If they are gone, nobody |
The highlighted row is the one this vulnerability lives in. It applies even when an updater exists: if the update subscription lapsed, if the purchase code sits in the account of an agency you no longer work with, or if the plugin was installed by uploading a file, the new version never arrives.
Which is how your updates screen can show nothing pending while a 9.8 sits in the plugins folder. Nothing is broken. Nobody ever told it where to look.
The updates screen shows what it knows about. The things it does not know about are exactly the things nobody checks.
What CVE-2026-8457 is
Definition. CVE-2026-8457 is an authentication bypass in the Social Login plugin by WPWeb for WordPress and WooCommerce, present in all versions up to and including 2.8.7, which lets an unregistered visitor obtain an administrator session knowing nothing but an email address.
The technical classification is CWE-289, authentication bypass by alternate name. The published severity vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: reachable over the network, low complexity, no privileges needed, no user interaction, high impact on everything. Every single parameter is in its worst position.
In plain English: the attacker does not need an account, does not need to guess anything, and does not need anyone to click on anything. They need an email address that already exists on your site.
Do you have it? Two minutes to find out
Precision matters here. There are dozens of plugins that add social buttons to the login form, and only one of them is this one.
- Admin access to your WordPress dashboard.
- Two minutes on Plugins › Installed Plugins.
- The name and the author, not just the name: you are looking for Social Login by WPWeb. The name alone belongs to other, unrelated plugins as well.
- The version number, printed under the description. 2.8.7 or lower means exposed; 2.8.8 or higher means patched.
- If you have file access, the folder is usually
woocommerce-social-logininsidewp-content/plugins/.
If you look after several sites and have WP-CLI, it is one line each:
# list plugins whose name contains "social", with version and status
wp plugin list --format=table --fields=name,status,version | grep -i social
# or straight to the point: which version do I have?
wp plugin get woocommerce-social-login --field=versionOne note on plugins that are installed but deactivated. A deactivated plugin does not run its code, so for this particular flaw it is not exploitable. But it stays on disk, and one distracted click reactivates it. If you are not using it, delete it — that is the cheapest maintenance there is.
What you do tonight, in ten minutes
- Check whether you have it, by name and author. Nine times out of ten this is where it ends and you go and have dinner.
- Take a backup before you touch anything. If your host takes automatic ones, confirm there is one from today.
- Update the plugin to 2.8.8 or higher. If the updater is present, one click. If not, download the package from your marketplace account and upload it.
- If you cannot update right now — purchase code lost, developer unreachable, site frozen for a launch — deactivate the plugin. The shop loses its social login buttons; customers sign in with email and password as always.
- Read the list of administrator users. One you do not recognise is enough to stop and call someone.
- End every open session and change the administrator passwords. If anyone was in, their session dies here.
- Write down the date. In six months you will want to know when you checked.
Step six from the command line looks like this. The second command is the one that genuinely invalidates open sessions, because it changes the keys the login cookies are signed with:
# list administrators: who exists, with which email, since when
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# end every session for every user
wp user session destroy --all --all-users
# regenerate the signing keys: invalidates any existing login cookie
wp config shuffle-salts
An email address is all it takes
When somebody signs in with Apple, Apple issues a signed document that says, in effect: this person really is [email protected], I vouch for it. It is a token — a digital ticket with a signature on it.
The receiving site has exactly one job: verify the signature. Apple publishes its keys for that purpose. A ticket without a valid signature is worth nothing.
In versions up to 2.8.7, the plugin opened the ticket and read the email inside it without checking the signature, and without checking who issued it, who it was issued for, or whether it had expired. Then it looked that email up among the site's users and opened a session. Without excluding any role — so including when the email belonged to an administrator.
It is a doorman who checks the name against the guest list but never looks at the ID. If you know the name of someone on the list, you walk in as them.
This is what makes the flaw serious rather than theoretical. Administrator addresses are not confidential: they are on the contact page, in replies to reviews, in the domain's whois record, in the signature of every email the shop sends. On many WordPress sites the author's username is public by design.
A defence that rests on something printed on your business cards is not a defence.
Patched on 27 July, disclosed on 1 August
The dates tell a story the bulletins do not, because bulletins only carry the publication date.
| Date | What happened | Where you can read it |
|---|---|---|
| 27 July 2026 | Version 2.8.8 ships. The changelog reads: "Fix: Fixed & Improved validation and verification of Apple Sign-In ID tokens" | The product listing on the marketplace |
| 1 August 2026 | The flaw becomes public as CVE-2026-8457, severity 9.8 | Security bulletin |
| 2 August 2026 | The advisory lands in the public vulnerability database with the full technical description | GitHub Advisory Database |
| 3 August 2026 | The trade press picks it up | Search Engine Journal, by Roger Montti |
| 7 August 2026 | The listing still shows 2.8.8 as the current version, with 3,564 sales at $39 | Checked by us on the day |
The first four rows come from the linked documents. The last is our own direct check of the public product listing on 7 August 2026, and it can change from one day to the next.
Five days between the fix and the alarm is good news: the author patched before the flaw went public. That is how it is supposed to work.
The uncomfortable part comes next. 3,564 sales is the number on the listing. It is not 3,564 sites — some purchases were never installed, some went onto several sites, and for a $39 plugin there are also copies downloaded elsewhere that receive no updates by definition. Nobody knows the real figure, but the error only runs in one direction: there are more exposed sites than sales, not fewer.
What the plugin registry says, checked today
The next question is always the same: fine, what do I put in its place? Before answering from memory we looked at the actual state of the public registry. On 7 August 2026 we queried the WordPress.org API for the most common social login slugs.
| Plugin | Status in the registry | Latest version |
|---|---|---|
| WooCommerce – Social Login (WPWeb) | Not present: it is a paid marketplace item | 2.8.8, of 27 July 2026 |
| Nextend Social Login and Register | Active | 3.1.26, updated 28 July 2026 |
| miniOrange Social Login and Register | Active | 7.8.1, updated 22 July 2026 |
| Social Login (oa-social-login) | Active, but stalled | 5.10.0, updated 2 December 2024 |
| Super Socializer | Closed on 18 June 2026, "this closure is temporary, pending a full review" | — |
| Wp social (facebook, google, twitter) | Closed on 25 September 2019, reason: licensing or trademark violation | — |
| social-login | Closed on 6 June 2018, reason: unused | — |
Source: the public API at api.wordpress.org/plugins/info/1.0/<slug>.json, queried from our own server on 7 August 2026. Closure reasons are quoted from the API response. We are not saying the closed plugins were insecure: the registry does not state that, and closures happen for administrative reasons too.
Two things stand out. First, the social login market is thinner than it looks from the outside: three of the historic names are closed. Second, look at the oa-social-login row. It is listed as active, but the last release is from December 2024 and it declares compatibility only up to WordPress 6.7.6, while the core is at 7.0.3. Which compresses fifteen years of this trade into one rule: check the last-updated date before you look at the star rating.
The third option, the least fashionable one, is to drop social login altogether. On a small shop it buys very little and it adds a dependency on three separate companies for the most sensitive thing on the site. That is not a rule — it is a question worth asking once you look at how many customers actually use it.
How to tell if someone already got in
Fair question, and the honest answer is that with stock tooling you cannot know for certain. You can look for the signs, and they are always the same ones:
- Administrator accounts you do not recognise, or ordinary users who became administrators. Check the registration date: an old account with a new role is worse news, not better.
- Plugins you did not install, usually with names that sound technical and harmless.
- Recently modified files inside the WordPress folders, especially
wp-content/uploads/, where nothing executable belongs. - Successful logins in the logs at hours when nobody was working. If you run a security plugin with a login log, the answer is there.
- Outgoing email nobody knows about, or your domain turning up on a spam blocklist.
If you find even one of these, the right move is not to clean up and hope. It is to isolate the site, preserve the logs, and rebuild from a known-good backup, updating before you go back online. Anyone who had administrator access also had time to leave a second door.
What updating does not fix
| What the update does | What it does not do |
|---|---|
| Closes the door | Does not evict anyone already inside. Open sessions stay valid until you end them. |
| Fixes the signature check | Does not remove users, plugins or files left behind by an earlier intrusion. |
| Brings you current today | Does not change the fact that the next update for that plugin is also yours to fetch. |
| Applies to this plugin | Says nothing about the other pieces bought outside the registry, which have exactly the same delivery problem. |
That last row is worth one afternoon, once: inventory the pieces that do not update themselves. Name, where it was bought, which account holds the licence, when it expires. On an average shop there are between three and ten. On the day an advisory lands, that list is the difference between ten minutes and an afternoon of phone calls.
The same week: WordPress 7.0.3
On 6 August, WordPress 7.0.3 came out — a security release fixing twelve vulnerabilities. The main one is rated 8.9 out of 10 and is described in the bulletin as follows: "WordPress is vulnerable to a pre-auth reflected XSS vulnerability on the login screen", with the possibility, under specific conditions, of escalating to code execution. The fix was backported as far as version 4.7.
We put the two stories side by side because together they make one point.
| WordPress 7.0.3 | Social Login 2.8.8 | |
|---|---|---|
| Severity | 8.9 | 9.8 |
| Released | 6 August 2026 | 27 July 2026 |
| How it reaches your site | By itself, within hours | Only if you go and get it |
| What you have to do | Confirm it arrived | Everything |
Sources: the official WordPress 7.0.3 announcement and Search Engine Journal's coverage of it from 6 August 2026, plus the CVE-2026-8457 advisory cited above.
The more severe of the two is the one your site will not repair on its own. That is not a coincidence, it is the rule. The WordPress core has an update distribution machine built over fifteen years. A $39 plugin has you.
The words, in a table
| Term | What it means |
|---|---|
| CVE | The universal identifier of a vulnerability, so everyone is discussing the same thing. |
| CVSS | The severity score from 0 to 10. Above 9 means remotely exploitable with no prerequisites. |
| Authentication bypass | Getting in without having credentials, rather than guessing them. |
| Identity token | The signed ticket with which a provider such as Apple vouches for who you are. |
| Digital signature | The part of the ticket that proves who issued it. It has to be verified, or it means nothing. |
| Session | The state of being logged in. It lives in a cookie and lasts until it is ended or expires. |
| Salts / signing keys | The site's secret strings used to sign login cookies. Changing them logs everybody out. |
Where you stand, in three thresholds
If you do not have this plugin, you are done in five minutes, and you have gained a useful question: which other pieces of my site do not update themselves? Ask it tonight, while it is on your mind.
If you have it at 2.8.8 or higher, you are clear on this flaw. Still walk the administrator list: if the plugin ran on an old version for a while, you do not know who passed through.
If you have any version up to 2.8.7, that is the most important thing in your evening. Update or deactivate, then check the administrators, then end all sessions. In that order, because ending sessions while the door is still open achieves nothing.
And if you are wondering whether your shop has other pieces in the same position, the answer is almost certainly yes. Building that inventory is day one of every site we take into managed hosting. It is not the most thrilling work in this trade, but it is the work that prevents evenings like this one.
Questions
Questions nobody has actually asked us
The advisory is days old, so no, nobody has asked us yet. These are the questions someone with an online shop would have, reading this on their phone at half past ten at night.
I have the plugin but I never enabled Apple login. Am I safe?
Do not count on it. The public description of the flaw concerns the Apple login handler inside the plugin, not a setting you switch on in the dashboard. Code that is present and active is code that is reachable.
Treat it as exposed: update, or deactivate the plugin until you can.
My host runs a security plugin. Doesn't that cover me?
Partly, and later than you would like. Some security services publish a rule for a known flaw shortly after it goes public, and then the request is blocked before it reaches your site. But that protection arrives once the flaw is already public — after the most dangerous window.
A firewall is a good second door. It is not a substitute for the update, and it matters for another reason too: what you decide at the front door also affects the visitors you want.
Why isn't this plugin in the WordPress.org directory in the first place?
Because the directory only carries free plugins under a compatible licence. Commercial plugins sold on marketplaces live outside it by design, which is a perfectly legitimate business model and also the reason your site has no way to check them.
The consequence is the one this article is about: the update channel is you.
Can I just delete the plugin instead of updating it?
Yes, and if you are not using the social buttons that is the better answer. Deleting removes the code from disk entirely, which is stronger than deactivating and stronger than patching something you do not need.
Customers keep signing in with email and password. Existing accounts created through a social provider still exist — check that those users have a usable password reset path before you remove the buttons.
Will updating break my checkout?
It is a maintenance release, so the risk is low, but zero risk does not exist on any site with customisations. Back up first, update, then immediately test the two things that matter: that you can log in, and that you can complete an order.
If you have a staging environment, do it there. If you do not, do it during a quiet hour.
I have lost the purchase code. What now?
The code lives in the marketplace account of whoever bought it — often not you, but the agency or developer who built the site. Ask them for it, and ask for it to be transferred to an account you control.
If that route is closed, the honest option is to deactivate the plugin and replace it with a maintained one. Buying it again at $39 is still cheaper than a compromised site.
How long before somebody actually tries it?
For flaws with this profile — network-reachable, no credentials, widespread platform — automated scanning starts within days of public disclosure. Nobody has to have singled you out; the bots try every address they can find.
So the practical answer is that the quiet window closed on 1 August. That is not a reason to panic. It is a reason to do the check tonight rather than at the weekend.
Is social login still worth it on a small shop?
It depends on how many people actually use it, and you have that number: look at how many of your registered customers arrived through a social provider. If it is a handful, you are maintaining three external dependencies for very little.
On a shop with many returning customers it measurably reduces friction. The answer is not ideological, it is in your own data.
Should I be worried about WordPress itself after twelve vulnerabilities in one release?
Not especially. Twelve issues in a single security release is a sign of an active security process, not a failing one — they were found, fixed together and backported to version 4.7. The release also installs itself.
What deserves your worry is the part of the stack with no such process, which is the point of everything above.
How do I avoid ending up here again in six months?
One list, refreshed once a year: every plugin and theme bought outside the WordPress.org registry, where the licence lives, in which account, when it expires. Twenty minutes the first time.
Then a ten-minute appointment each month to check those few pieces by hand. It is boring, and it works.
Last updated: 7 August 2026. The technical description and severity score come from the CVE-2026-8457 advisory published on 2 August 2026 in the GitHub Advisory Database, read the same day; the press coverage is Roger Montti's article in Search Engine Journal of 3 August. Version, release date, changelog, sales count and price of the plugin were verified by us on the public product listing on 7 August 2026. The status of alternative plugins comes from the public WordPress.org API, queried from our own server the same day. We update this page if a version after 2.8.8 appears or if the advisory is amended.
