WooCommerce Social Login: Forged Apple JWT Bypass (CVE-2026-8457)

Decoding a JWT is not verifying it. That distinction is the entire story of CVE-2026-8457, a critical authentication bypass in the WooCommerce - Social Login plugin, disclosed August 1, 2026. It carries a CVSS score of 9.8, and it lets an unauthenticated attacker log in as any user on the site, administrators included. All versions up to and including 2.8.7 are affected. Version 2.8.8 fixes it.

The bug lives in the plugin's "Sign in with Apple" handler. When a visitor completes Apple's login flow, Apple hands back an id_token, a JSON Web Token that asserts who the user is. The plugin took that token, base64-decoded its payload, and trusted whatever email address it found there. It never checked whether the token was real.

WooCommerce - Social Login adds one-click login buttons for Google, Facebook, Apple, and other providers to WooCommerce checkout and account pages, so store owners can cut down on abandoned signups. That convenience depends entirely on the plugin doing its half of the handshake correctly: taking whatever the provider sends back and confirming it's genuine before treating it as proof of identity. This CVE is what happens when that half is skipped.

How the flaw works

A JWT has three parts separated by dots: a header, a payload, and a signature. Both the header and payload are just base64url-encoded JSON, and anyone can decode them with one line of code and no secret. That's by design. A JWT is meant to be readable. What makes it trustworthy isn't the payload, it's the signature.

The signature is a cryptographic proof, computed over the header and payload, that only the issuer (Apple, in this case) could have produced. Verifying it means fetching Apple's public keys and checking that the signature actually matches. Skip that step and the payload is just a string. Anyone can build a JWT-shaped string with three base64 segments and any claims they want. It will decode fine. It proves nothing.

WooCommerce Social Login's Apple handler decoded the payload and stopped there. It read the email claim out of the JSON and looked up a WordPress account matching that address, then logged the visitor in as that user. There was no call to Apple's public key endpoint, no signature check, nothing standing between an attacker's forged claim and an authenticated session.

A correct id_token handler runs four checks before trusting anything inside the payload:

1. Signature against the issuer's published JSON Web Key Set (JWKS). Apple's is at appleid.apple.com/auth/keys.
2. Issuer (iss) matches the expected value, https://appleid.apple.com.
3. Audience (aud) matches your app's client ID, so a token minted for a different app can't be replayed against yours.
4. Expiry (exp) hasn't passed.

This plugin skipped all four. Any of the four alone would have blocked the forged-token attack; skipping every one of them is what makes this a 9.8.

The nonce that wasn't a secret

CVE-2026-8457 has a second component that compounds the first. WordPress login flows are usually gated by a nonce, a per-session token meant to prove the request came from a real page load and isn't a replayed or cross-site request. The nonce guarding this plugin's login endpoint was printed into a localized JavaScript object on the login page, readable by any unauthenticated visitor who loaded the page and viewed source.

So the one barrier standing in front of the forged-token path wasn't actually a barrier. It was public. An attacker didn't need to steal a session or trick a logged-in user into anything; the value required to invoke the flow was sitting in the page's own script tags for anyone to read.

Who is affected

Every site running WooCommerce - Social Login 2.8.7 or earlier with Apple login enabled is exploitable, and no attacker authentication is required. WordPress accounts that were never linked to Apple are still reachable, because the vulnerable code path trusts the email claim to find an account, not a pre-existing Apple-linked identity. If an administrator's email address is guessable or public (and admin emails often are), that account is the highest-value target on the site. From there, an attacker with an admin session can install a plugin, edit theme files, or create new privileged users, and on a WooCommerce store that also means direct exposure of customer accounts and order history sitting behind the same login form.

The pattern: hand-rolled OIDC handlers

"Sign in with X" integrations are authentication code, full stop. They deserve the same scrutiny as a password check or a session cookie, not the treatment of a convenience feature bolted onto a plugin's settings page.

OpenID Connect, the protocol underneath "Sign in with Apple," "Sign in with Google," and similar flows, exists specifically to formalize this. It defines exactly which claims to check and how to fetch the keys to check them against. Every major language has a maintained library that implements this correctly: verify signature against JWKS, check iss, check aud, check exp, and only then hand you the claims.

Writing a JWT parser from scratch to save a dependency is where bugs like this one come from, because it's easy to write code that decodes a token and looks like it works. A forged token decodes identically to a real one. The only thing that tells them apart is the signature check, and that's precisely the step that's invisible in a quick manual test with a real Apple login. A developer clicks through the flow with their own Apple ID, sees a correct login, and ships it. The missing verification never shows up until someone who isn't supposed to have access goes looking for it.

Here's the shape of the difference, in generic PHP:

// Vulnerable: trusts whatever the payload claims
$payload = json_decode(base64_decode(explode('.', $id_token)[1]), true);
$user = get_user_by('email', $payload['email']); // no proof this is real

// Correct: verify before you trust anything in the payload
$jwks = fetch_jwks('https://appleid.apple.com/auth/keys');
$claims = JWT::decode($id_token, $jwks); // throws on bad signature
if ($claims->iss !== 'https://appleid.apple.com'
    || $claims->aud !== APPLE_CLIENT_ID
    || $claims->exp < time()) {
    throw new AuthException('invalid token');
}
$user = get_user_by('email', $claims->email);

The first version compiles, runs, and logs real users in correctly during testing, because real Apple tokens have real emails in the payload. It only fails the moment someone hands it a token they made up themselves. That gap between "works in every test I ran" and "works when someone attacks it" is exactly what a security review is supposed to catch before release.

This isn't the first OAuth-adjacent WordPress plugin to get burned by trusting a token it never checked. MonsterInsights' OAuth token theft came from a different angle, an exposed token rather than a forged one, but the root cause category is the same: authentication code that treats a bearer credential as self-certifying instead of independently verifying it. The User Registration membership auth bypass is a third variation, a login path that skipped a check its own design assumed was in place. Auth bypasses cluster around exactly these moments: a handler that assumes a token, a nonce, or a claim is trustworthy because it arrived in the expected shape.

What to do now

Update WooCommerce - Social Login to 2.8.8 or later immediately. This isn't a "patch during your next maintenance window" bug; it's unauthenticated and the exploit path requires nothing more than crafting a token and hitting the login endpoint.

If your site ran 2.8.7 or earlier with Apple login enabled, treat it as a possible compromise until proven otherwise:

• Check wp_users and wp_usermeta for admin accounts created or promoted around dates you can't account for, especially any created outside your normal onboarding flow.
• Review recent logins on privileged accounts for IP addresses or user agents that don't match the account owner's usual pattern.
• Look for new plugin installs, theme file edits, or new mu-plugins timestamped after your last known-good state. A forged login has full account privileges, so anything the compromised account's role allows is in scope.
• Check for new application passwords or REST API tokens issued to existing users, since a forged admin session can generate its own persistent access.
• If any of the above turns up something, rotate WordPress secret keys and salts, force a password reset for every user, and treat the WooCommerce customer and order tables as potentially exposed. If you catch broader signs your WordPress site was hacked, work through that checklist alongside this one rather than assuming this single flaw explains everything you're seeing.

There's no configuration workaround that closes this short of updating. Disabling Apple login in the plugin's settings removes the vulnerable path if you can't update immediately, but the fixed version is the only real remediation. Because the flaw sits in a bundled JWT-handling routine rather than a third-party library the plugin depends on, a manual patch that only replaces that one function is possible if you're comfortable editing plugin code directly, but it's a stopgap. Updating to 2.8.8 replaces it properly and picks up any other hardening WPWeb shipped in the same release.

WP Vanguard's scanner flags plugins running below their patched version, including this one, as part of routine site checks.

References

• NVD - CVE-2026-8457
• GitHub Advisory Database: GHSA-qwc9-q2f8-q72q
• IONIX Threat Center: CVE-2026-8457
• Apple Developer Documentation: Verifying a User
• Apple Developer Documentation: Authenticating Users with Sign in with Apple