ANALYSIS · f74275e3· FINISHED 2026-06-13 · PATCHDIFF

melapress-login-security2.1.1 → 2.2.0✓ COMPLETED

Files45

Vulnerable19

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-2025-6895

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 45 CVE 1 Vuln 19

SORT

1 files · page 1/1

app/modules/temporary-logins/class-temporary-logins.php

AI: 3 vulnerabilities

CWE-352: Cross-Site Request Forgery (CSRF)CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')CWE-400: Uncontrolled Resource Consumption CVE-2025-6895

#%!d(float64=026)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-6895

Security writeup for CVE-2025-6895

✓ 1 FILE

## The Exploit

An unauthenticated attacker who knows an arbitrary WordPress user's meta key and can predict or enumerate meta values can bypass authentication entirely and log in as that user. No nonce, no password, no session required.

```http
GET /wp-login.php?mls_temp_login_token=attacker_controlled_value HTTP/1.1
Host: target.wordpress.local
User-Agent: Mozilla/5.0
Cookie: wordpress_logged_in=; wp-settings-time=
```

When the token parameter matches a user meta value stored in the database (e.g., a temporary login token previously created by an admin), the `get_valid_user_based_on_token()` function retrieves that user's ID and logs them in via `wp_set_current_user()` and `wp_set_auth_cookie()` without any capability checks. An attacker observes a successful 302 redirect to `/wp-admin/` with an authenticated session cookie. If the target user is an administrator, the attacker gains full site control.

---

## What the Patch Did

**Before:**
```php
public static function get_valid_user_based_on_token( $token ) {
    if ( empty( $token ) ) {
        return false;
    }

global $wpdb;
    $meta_key = 'mls_temp_user_expires_on';

$sql = '
        SELECT  ID, display_name
        FROM        ' . $wpdb->users . ' INNER JOIN ' . $wpdb->usermeta . '
        ON ' . $wpdb->users . '.ID = ' . $wpdb->usermeta . '.user_id
        WHERE ' . $wpdb->usermeta . '.meta_key = "mls_temp_user_token"
        AND ' . $wpdb->usermeta . '.meta_value = %s
        AND ' . $wpdb->usermeta . '.user_id NOT IN (
            SELECT user_id FROM ' . $wpdb->usermeta . ' WHERE meta_key = "mls_temp_user_expires_on" AND CAST( meta_value AS UNSIGNED ) < %d
        )
    ';

$result = $wpdb->get_row( $wpdb->prepare( $sql, $token, time() ) );

if ( ! empty( $result ) && ! empty( $result->ID ) ) {
        wp_set_current_user( $result->ID );
        wp_set_auth_cookie( $result->ID );
        return $result;
    }

return false;
}
```

**After:**
```php
public static function get_valid_user_based_on_token( $token ) {
    if ( empty( $token ) ) {
        return false;
    }

if ( ! \is_user_logged_in() ) {
        return false;
    }

global $wpdb;
    $meta_key = 'mls_temp_user_expires_on';

$sql = '
        SELECT  ID, display_name
        FROM        ' . $wpdb->users . ' INNER JOIN ' . $wpdb->usermeta . '
        ON ' . $wpdb->users . '.ID = ' . $wpdb->usermeta . '.user_id
        WHERE ' . $wpdb->usermeta . '.meta_key = "mls_temp_user_token"
        AND ' . $wpdb->usermeta . '.meta_value = %s
        AND ' . $wpdb->usermeta . '.user_id NOT IN (
            SELECT user_id FROM ' . $wpdb->usermeta . '.meta_key = "mls_temp_user_expires_on" AND CAST( meta_value AS UNSIGNED ) < %d
        )
    ';

$result = $wpdb->get_row( $wpdb->prepare( $sql, $token, time() ) );

if ( ! empty( $result ) && ! empty( $result->ID ) ) {
        wp_set_current_user( $result->ID );
        wp_set_auth_cookie( $result->ID );
        return $result;
    }

return false;
}
```

The patch adds a single authorization gate: `if ( ! \is_user_logged_in() ) { return false; }` at the start of `get_valid_user_based_on_token()`. This is the WordPress `is_user_logged_in()` function, which checks whether the current request carries a valid, pre-existing authentication session. The function now refuses to process temporary login tokens unless the caller is already authenticated.

---

## Root Cause

**CWE-862: Missing Authorization** combined with **CWE-287: Improper Authentication**.

The vulnerable code path flows as follows: when a user lands on the login page with the `mls_temp_login_token` parameter set, a hooked handler (not shown in the diff but referenced by the function signature) calls `get_valid_user_based_on_token()` with the attacker-controlled token from `$_REQUEST['mls_temp_login_token']`. That parameter enters as untrusted user input. The function performs a SQL query using `$wpdb->prepare()` to escape it, preventing injection, but does *not* verify that the requester is already logged in. It then directly calls `wp_set_auth_cookie()` on the queried user, elevating an anonymous request to authenticated. The trust boundary crossed is: unauthenticated requester → authenticated session, with no authorization check in between.

---

## Why It Works

The load-bearing line is `if ( ! \is_user_logged_in() ) { return false; }`.

Without this check, an attacker can call the function from unauthenticated context, query the temporary-login meta table for any token value they know or guess, and immediately authenticate as that user. Removing this single line restores the vulnerability.

The surrounding code—the SQL prepare, the expiration check, the user existence validation—is defence in depth: it prevents *invalid* tokens from triggering a login, and it stops expired temporary-login sessions from being reused. But none of it enforces the critical rule: "only already-authenticated users may perform token-based re-authentication." That rule lives in the one line the patch adds. The other lines were already there; the engineer correctly identified that the missing piece was the authorization gate itself, not the input handling.

---

## Hardening Checklist

- **Add `is_user_logged_in()` checks before re-authentication flows.** Any function that calls `wp_set_auth_cookie()` or `wp_set_current_user()` must first verify the requester is already authenticated via `is_user_logged_in()`, unless the function is explicitly designed for first-time login (e.g., `wp_authenticate()` in core).

- **Audit all query handlers hooked to `init` or `wp_loaded`.** If a handler processes `$_REQUEST` or `$_GET` parameters and performs privilege-level changes, enumerate every code path and confirm each one has a capability check (`current_user_can()`) or authentication check (`is_user_logged_in()`) at the entry point.

- **Use `wp_verify_nonce()` for all state-changing operations.** The temporary-login feature should require a nonce even for authenticated users to prevent CSRF. Verify the nonce before accepting the `mls_temp_login_token` parameter, not after querying the database.

- **Test unauthenticated access to every authentication-related endpoint.** In your test suite, confirm that calling your token-exchange function with a valid token but no prior session returns `false` and does not call `wp_set_auth_cookie()`.

---

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-6895

CVE CVE-2025-6895

PRODUCT melapress-login-security

AFFECTED ≤ 2.1.1

FIXED IN 2.2.0

STATUS Generated

Security writeup · CVE-2025-6895

Source files · 1

app/modules/temporary-logins/class-temporary-logins.php Linked

↗ NVD