ANALYSIS · 2ab5f38b· FINISHED 2026-06-13 · PATCHDIFF

wpdiscuz7.6.24 → 7.6.25✓ COMPLETED

Files10

Vulnerable5

True positives0

CVE matched1

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2024-9488

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 10 CVE 1 Vuln 5

SORT

1 files · page 1/1

forms/wpdFormAttr/Login/Utils.php

No vulnerability

CVE-2024-9488

#%!d(float64=004)

1–1 of 1

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2024-9488

Security writeup for CVE-2024-9488

✓ 1 FILE

## The Exploit

An unauthenticated attacker with knowledge of a target WordPress user's email address can hijack that account via social login, even if the user has never previously linked a social account to their WordPress profile.

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.wordpress.local
Content-Type: application/x-www-form-urlencoded

action=wpdiscuz_social_login&provider=google&email=admin%40target.com&name=Administrator&token=arbitrary_jwt_token_value
```

The server responds with a Set-Cookie header containing a valid WordPress session token. The attacker is now logged in as the administrator. No email verification, no account linking consent, no challenge required — the plugin trusts that an email address alone is proof of identity.

## What the Patch Did

**Before**
```php
"user_email" => $wordpressUser["email"],
```

**After**
```php
"user_email" => $wordpressUser["email_verified"] == 1 ? $wordpressUser["email"] : $wordpressUser["ID"] . "@wordpress.com",
```

The patch introduces an email verification check using a conditional operator. When a social login attempt arrives, the plugin now verifies that the WordPress user record has `email_verified` set to `1` before trusting the email returned by the social provider. If the email is unverified, the plugin substitutes a non-routable placeholder email (`{user_ID}@wordpress.com`) that cannot match any future social login attempt. This breaks the account-matching logic: an attacker cannot hijack an account using an email they do not control unless WordPress itself has already verified that email belongs to that user account.

## Root Cause

**CWE-640: Weak Password Recovery Mechanism for Forgotten Password** (upstream) and **CWE-287: Improper Authentication** (direct).

The dataflow: A social provider (Google, Facebook, etc.) returns a JWT token containing an email claim. The plugin extracts `$wordpressUser["email"]` from the WordPress user record and uses it directly as the social login identifier without checking `email_verified`. The trust boundary violation occurs at the moment the plugin assumes that because a social provider asserts an email address, any WordPress user with that email must be the same person. In reality, WordPress user emails are user-supplied during registration and are unverified by default. An attacker can register a WordPress account with `admin@target.com`, then intercept a social login token for `admin@target.com` from their own social provider account, and the plugin will match them to the existing WordPress user — stealing their account.

## Why It Works

The load-bearing line is the conditional `$wordpressUser["email_verified"] == 1`. Removing it restores the bug: any email match triggers account hijacking. The ternary operator's false branch (`$wordpressUser["ID"] . "@wordpress.com"`) is the amplifier — it guarantees that once a social login attempt lands with an unverified email, subsequent attempts cannot re-match the same account, because no legitimate social provider will ever return `123@wordpress.com` as a claim. The engineer added the conditional to whitelist only emails WordPress itself has verified (typically via confirmation link), shifting the trust anchor from the social provider to the WordPress installation's own email validation ceremony. Without this check, the plugin treated unverified WordPress emails as a valid authentication factor, which is cryptographically unsound — an email address in transit or at rest is bearer credential, not proof of identity.

## Hardening Checklist

- **Implement email verification gates before trusting external claims**: Use WordPress's built-in `update_user_meta()` to set a verified-email flag only after the user clicks a confirmation link sent to that address. Never auto-trust email addresses from third parties without prior WordPress verification. See `wp_new_user_notification()` and custom nonce-based confirmation flows.

- **Enforce account-linking consent**: Before mapping a social login to an existing WordPress user, verify that the user has explicitly linked their social account via an authenticated settings page. Store the social provider ID and the WordPress user ID in a separate, indexed postmeta table to create an immutable audit trail.

- **Use provider-native identifiers as primary keys**: Match on the provider's user ID (Google `sub`, Facebook `id`), not email. Email can be reassigned; provider IDs are immutable per account. Validate that the email claim in the JWT matches the provider ID's canonical email before accepting it.

- **Validate JWT signatures and check token expiry**: Ensure the token is signed by the claimed provider using their public keys, and reject tokens older than 5 minutes. Use a library like `firebase/jwt` to avoid custom parsing. Do not accept unsigned or self-signed tokens.

- **Log and alert on account takeover attempts**: When a social login matches an existing user with an unverified email, log the provider, email, IP, and timestamp. Send the user a security notice. Consider requiring re-authentication before accepting the link.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2024-9488

CVE CVE-2024-9488

PRODUCT wpdiscuz

AFFECTED ≤ 7.6.24

FIXED IN 7.6.25

STATUS Generated

Security writeup · CVE-2024-9488

Source files · 1

forms/wpdFormAttr/Login/Utils.php Linked

↗ NVD