ANALYSIS · 74aecd81· FINISHED 2026-06-13 · PATCHDIFF

loginizer1.9.2 → 1.9.3✓ COMPLETED

Files3

Vulnerable0

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-10097

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 3 CVE 1 Vuln 0

SORT

1 files · page 1/1

main/social-login.php

No vulnerability

CWE-640: Weak Password Recovery Mechanism for Forgotten Password CVE-2024-10097

#%!d(float64=003)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-10097

Security writeup for CVE-2024-10097

✓ 1 FILE

## The Exploit

An unauthenticated attacker with control over a social identity provider (or ability to register an account on one) can log in as any existing WordPress user, including administrators, by submitting a social login callback with an unverified email address matching a target account.

```http
GET /wp-login.php?loginizer_social_login=google&code=ATTACKER_CONTROLLED_AUTH_CODE HTTP/1.1
Host: target-wordpress.local
User-Agent: Mozilla/5.0

```

The attacker crafts or intercepts a social login callback where the `code` parameter is issued by a provider (Google, Facebook, etc.) for an account with email `admin@target-wordpress.local` but where `emailVerified` is `false` in the provider's user profile object. When the callback is processed by `social-login.php`, the plugin retrieves the user profile from HybridAuth and matches the email address to the existing WordPress admin account without verifying that the provider has actually confirmed ownership of that email. The attacker receives a valid WordPress session cookie and full access to the administrator account.

## What the Patch Did

**Before**

```php
$adapter = $hybridauth->getAdapter($provider);
$userProfile = $adapter->getUserProfile();
$accessToken = $adapter->getAccessToken();

$data = [
    'access_token' => $accessToken,
```

**After**

```php
$adapter = $hybridauth->getAdapter($provider);
$userProfile = $adapter->getUserProfile();
$accessToken = $adapter->getAccessToken();

// Check if the user have account which is verified
if(empty($userProfile->emailVerified)){
    self::$error['login_failed'] = __('The social account you are using does not have a verified email.', 'loginizer');
    $adapter->disconnect();
    self::trigger_error();
    return;
}

$data = [
    'access_token' => $accessToken,
```

The patch introduces an explicit email verification check using the `emailVerified` property returned by the social provider's user profile object. Before processing the login, the code now validates that `$userProfile->emailVerified` is not empty. If the check fails, the plugin disconnects the adapter and triggers an error, preventing authentication. This is a positive security control — a blocklist that rejects unverified identities rather than assuming all profile data from a provider is trustworthy by default.

## Root Cause

**CWE-640: Weak Verification of Cryptographic Signature** (and CWE-287: Improper Authentication).

The vulnerability stems from insufficient trust boundary validation in the social login callback handler. When a user initiates social login, HybridAuth returns a user profile object containing email and verification status. The plugin's original code trusted that any email address in `$userProfile->email` belonged to the authenticated user without independently validating the `emailVerified` flag. An attacker who controls a social account (or registers one) can supply any email address during the provider's OAuth flow. Providers like Google accept unverified email claims in certain contexts or allow accounts with unverified secondaryemails. The plugin's dataflow — extracting email from the provider response, querying `wp_users` by that email, and issuing a session without confirming email ownership — crossed the trust boundary at the provider without a verification gate. The attacker-controlled value is the email address in the provider callback; the sink is the WordPress user lookup and session creation; the unchecked boundary is the provider's claim of email ownership.

## Why It Works

The load-bearing line is the conditional: `if(empty($userProfile->emailVerified))`. Removing this check alone would restore the vulnerability — the plugin would continue accepting unverified emails and matching them to WordPress accounts. The additional lines (`$adapter->disconnect()`, `self::trigger_error()`, and `return`) are defence-in-depth housekeeping: they ensure the adapter is cleaned up, an error is logged for audit visibility, and the function exits immediately to prevent any further processing. However, without the conditional itself, no amount of cleanup prevents the attack. The engineer added the extra statements because security controls should fail safely and log intent — a bare `return` leaves ambiguity about whether an error occurred, whereas an explicit disconnect and error trigger signal to the wider application and to administrators (via logs) that authentication was refused due to unverified email, not a network timeout or malformed response.

## Hardening Checklist

- **Validate third-party claims against provider-specific trust signals**: Always check provider-issued verification flags (like `emailVerified`, `email_verified`, or equivalent) before trusting identity claims. Use HybridAuth's profile metadata fields rather than assuming all populated fields are verified.

- **Implement email verification for social-linked accounts**: Before linking a social provider account to an existing WordPress user, send a verification email to that address or require the user to confirm the link in their WordPress dashboard. Do not auto-link based solely on email match.

- **Log authentication failures with sufficient context**: Call `wp_insert_activity_log()` (if available via a logging plugin) or write to `error_log()` with the provider, email, and reason for rejection. This surfaces patterns of failed social login attempts that indicate probe attacks.

- **Add a rate limit or CAPTCHA to the social login callback handler**: Use a transient or a third-party service like Cloudflare to throttle repeated failed social login attempts from the same IP or email. This slows account enumeration and takeover attempts.

- **Enforce email domain whitelisting for administrative users** (if applicable): If the WordPress site has a small set of allowed administrator email domains (e.g., `@company.com`), add a check in the social login handler to reject social accounts with email addresses outside that set before creating a session.

## References

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

CVE CVE-2024-10097

PRODUCT loginizer

AFFECTED ≤ 1.9.2

FIXED IN 1.9.3

STATUS Generated

Security writeup · CVE-2024-10097

Source files · 1

main/social-login.php Linked

↗ NVD