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

wp-job-portal2.1.6 → 2.1.7✓ COMPLETED

Files35

Vulnerable14

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

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 35 CVE 2 Vuln 14

SORT

2 files · page 1/1

modules/configuration/controller.php

AI: 2 vulnerabilities

CWE-639: Authorization Bypass Through User-Controlled KeyCWE-1025: Comparison Using Wrong Factors CVE-2024-7950

#%!d(float64=008)

modules/configuration/model.php

AI: 1 vulnerabilities

CWE-269: Improper Privilege Management CVE-2024-7950

#%!d(float64=009)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-7950

Security writeup for CVE-2024-7950

✓ 2 FILES

## The Exploit

An unauthenticated attacker can POST to the vulnerable plugin's configuration controller and modify arbitrary plugin settings without admin credentials.

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

action=wpjobportal_checkFormRequest&module=configuration&controller=configuration&method=storeConfig&isgeneralbuttonsubmit=1&wpjobportal_setting_key=arbitrary_config_value&wpjobportal_nonce=VALID_NONCE_HERE
```

The response will be a successful 200 OK with a JSON confirmation that settings were saved. An attacker observes that their arbitrary configuration values persist in the WordPress options table and trigger side effects (disabled registration, injected content, altered email templates, etc.) visible across the front-end or admin panel. Because the plugin fails to check `current_user_can('manage_options')` before calling `storeConfig()`, unauthenticated users or low-privilege accounts bypass the nonce-only protection and achieve unauthorized configuration modification.

---

## What the Patch Did

**Before**

```php
if (! wp_verify_nonce( $nonce, 'wpjobportal_configuration_nonce') ) {
     die( 'Security check Failed' );
}
$data = WPJOBPORTALrequest::get('post');
```

```php
function storeConfig($data) {
    if (empty($data))
        return false;

if ($data['isgeneralbuttonsubmit'] == 1) {
```

**After**

```php
if (! wp_verify_nonce( $nonce, 'wpjobportal_configuration_nonce') ) {
     die( 'Security check Failed' );
}
if (!current_user_can('manage_options')) { //only admin can change it.
    return false;
}
$data = WPJOBPORTALrequest::get('post');
```

```php
function storeConfig($data) {
    if (empty($data))
        return false;
    if (!current_user_can('manage_options')) { //only admin can change it.
        return false;
    }

if ($data['isgeneralbuttonsubmit'] == 1) {
```

The patch added a capability check using `current_user_can('manage_options')` in both the controller layer and the model layer. This WordPress API function verifies that the current user is an administrator and has permission to manage plugin options. Without this check, nonce validation alone is insufficient — a valid CSRF token proves the request came from an authenticated session, but does not prove the user has authorization to perform the action. The patch enforces the missing authorization boundary by rejecting any request from non-admin users, even if they hold a valid nonce.

---

## Root Cause

**CWE-269: Improper Access Control (Missing Authorization Check)** and **CWE-862: Missing Authorization**.

The vulnerable code path accepts a POST parameter `module=configuration` which routes to the configuration controller. The controller verifies the nonce token (`wp_verify_nonce()`) but omits the capability check (`current_user_can('manage_options')`). The attacker-controlled `POST` data flows directly from `WPJOBPORTALrequest::get('post')` into the `storeConfig()` function without any capability gate. This crosses a critical trust boundary: the code assumes that any user holding a valid nonce is authorized to modify settings, when in fact only administrators should be. The vulnerability chain is: unauthenticated or low-privilege POST → nonce passes → no capability check → arbitrary configuration stored in WordPress options.

---

## Why It Works

The load-bearing line is `if (!current_user_can('manage_options')) { return false; }`. Removing it re-opens the vulnerability. The nonce check alone cannot fix this bug because nonces protect against CSRF (cross-site request forgery), not authorization. A nonce proves the request came from an authenticated session; it does not prove the user is an admin. The engineer correctly added the capability check at two layers — controller and model — because defense-in-depth prevents the vulnerability even if one layer is bypassed or refactored. A direct call to `storeConfig()` from a different code path would still fail if the model layer guards it. Conversely, if only the controller checked capabilities and the model did not, a future developer might call `storeConfig()` directly from an AJAX endpoint and accidentally re-expose the bug.

---

## Hardening Checklist

- **Use `current_user_can()` at every authorization boundary.** For any function that modifies WordPress state (settings, posts, users), verify capability at the entry point (controller) *and* inside the function (model). Do not rely on nonce checks to enforce roles.

- **Implement a default-deny switch statement.** Add a `default: exit;` case to any switch statement that routes user-controlled input (`module`, `method`, `action`). This prevents accidental fallthrough to unintended code paths.

- **Never trust authentication alone.** Nonce verification (`wp_verify_nonce()`) proves the request is legitimate; it does not prove the user is authorized. Always pair nonce checks with capability checks using `current_user_can()` before sensitive operations.

- **Guard at both boundaries.** If a function performs a sensitive operation, add authorization checks in the controller (AJAX handler) *and* inside the model function. This prevents future refactoring from accidentally exposing the functionality through a different endpoint.

- **Audit `get('post')` and `get_post_data()` calls.** Anywhere the plugin retrieves POST data, ensure it flows through sanitization (`sanitize_text_field()`) and authorization checks before being passed to update functions.

---

## References

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

CVE CVE-2024-7950

PRODUCT wp-job-portal

AFFECTED ≤ 2.1.6

FIXED IN 2.1.7

STATUS Generated

Security writeup · CVE-2024-7950

Source files · 2

modules/configuration/controller.php Linked

modules/configuration/model.php Linked

↗ NVD