On August 1, 2026, Wordfence disclosed a critical authentication bypass in the WooCommerce – Social Login plugin (WPWeb Elite), tracked as CVE-2026-8457 (CVSS 9.8).
The short version: the plugin's Apple login handler accepts an id_token, decodes its base64 payload — and never verifies the JWT signature, issuer, audience, or expiry. Combined with a login nonce that's publicly exposed via wp_localize_script, an unauthenticated attacker can log in as any existing WordPress user, including administrators, by forging a token whose payload contains the target's email.
No password. No 2FA. No user interaction. Just an email address.
The technical breakdown
The vulnerable flow, in pseudocode terms:
// What the plugin does (vulnerable):
const payload = JSON.parse(base64Decode(id_token.split('.')[1])); // decode only
const email = payload.email;
const user = getUserByEmail(email);
loginAs(user); // no signature check, no iss/aud/exp validation
// What it should do:
const jwt = verifySignature(id_token, APPLE_PUBLIC_KEYS); // via JWKS
assert(jwt.iss === 'https://appleid.apple.com');
assert(jwt.aud === YOUR_CLIENT_ID);
assert(jwt.exp > now());
const email = jwt.payload.email;
The two problems stack:
-
Missing JWT validation — the handler decodes the payload without verifying it was signed by Apple (
CWE-289, Authentication Bypass by Alternate Name). - Public nonce — the security nonce required to invoke the login flow is emitted to unauthenticated users via a localized JS object on the login page, so there's no client-side gate either.
The plugin resolves the WordPress user by email from the forged payload, with no role exclusion, and immediately issues an authenticated session.
Affected versions & fix
| Detail | Value |
|---|---|
| Plugin | WooCommerce – Social Login (WPWeb Elite, CodeCanyon) |
| Affected | <= 2.8.7 |
| Fixed | 2.8.8 |
| CVSS | 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) |
| CWE | CWE-289 |
| Researcher | Rafie Muhammad (Lead Security Researcher, Patchstack — credited via Wordfence's PRISM researcher program) |
| Disclosed | August 1, 2026 (Wordfence Threat Intelligence) |
| Exploitation status | None confirmed at disclosure (Aug 1, 2026) |
References: Wordfence vulnerability entry · NVD: CVE-2026-8457
Note: this is a CodeCanyon premium plugin — updates don't flow through the usual WordPress.org free-plugin channel, so affected stores often patch late.
Why this matters to developers
This is the third authentication-related flaw Wordfence has logged for this plugin family:
- CVE-2024-7503 (Aug 2024): Authentication Bypass to Account Takeover via loose comparison of an activation code, CVSS 9.8
- CVE-2024-10114 (Nov 2024): Authentication Bypass via WordPress.com OAuth provider — insufficient verification of the user returned by the token, CVSS 8.1
- CVE-2026-8457 (Aug 2026): Forged Apple JWT auth bypass, CVSS 9.8
Three critical-to-high auth bypasses in two years, all in the same "trust the token/claim without properly verifying it" family, is a pattern worth noting — not just a one-off bug.
Auth code is genuinely hard to get right, and the pattern here — decode-then-trust instead of verify-then-trust — is one of the most common JWT mistakes in the wild. If you build or maintain WooCommerce sites:
-
Always verify JWTs against the provider's JWKS endpoint. Signature first, then
iss,aud,exp, and any provider-specific claims (e.g. Apple'snonceclaim if you use the Sign in with Apple nonce). -
Never expose the auth nonce to unauthenticated clients. If a nonce is in
wp_localize_script, it's not a security control — it's a formality. - Resolve accounts with role exclusion in mind. Even a legitimate flow shouldn't auto-login into an administrator account purely from a provider email without additional checks.
- Treat paid/CodeCanyon plugins as first-class update targets. They don't get WordPress.org's auto-update pipeline; schedule manual checks or use a license-manager integration.
Remediation checklist for affected stores
- Update to 2.8.8 (via CodeCanyon downloads or the plugin's license-connected updater).
- Audit Users → All Users for unrecognized admin accounts, especially created on/after Aug 1, 2026.
- Review access logs for unusual requests to the social-login callback endpoints around the disclosure window.
- Check for signs of post-exploitation (new admin users, unfamiliar plugins/themes installed, modified files, unexpected outbound requests) — not just the login itself, since a compromised admin session can be used to plant persistence.
- If you can't update immediately, consider disabling the Apple login provider in plugin settings as a temporary mitigation — it disables the affected handler until you patch.
The takeaway
CVE-2026-8457 is a reminder that "log in with X" buttons are only as safe as the verification code behind them. A missing signature check turned a customer convenience into a full account-takeover path. The fix is one version — but only if you know you run the plugin and you act before attackers decide it's worth their time.
Originally published on WardenBit.
Top comments (2)
The decode-then-trust approach, as seen in the vulnerable WooCommerce Social Login plugin, is a common pitfall in JWT handling, and it's crucial to prioritize verification against the provider's JWKS endpoint. I've encountered similar issues in the past where missing signature validation led to authentication bypasses, and it's essential to remember that
iss,aud, andexpclaims are just as important as the signature itself. The fact that this is the third authentication-related flaw in this plugin family highlights the need for thorough security audits and testing, especially in authentication code. What are some best practices for implementing robust JWT validation in WordPress plugins, and how can we ensure that security nonces are properly protected from unauthenticated clients?Super interesting! I'm curious if the JWT validation failure was specifically due to
kidor signature