ANALYSIS · 6b582f69· FINISHED 2026-06-13 · PATCHDIFF

js-support-ticket2.8.6 → 2.8.7✓ COMPLETED

Files7

Vulnerable3

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

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 7 CVE 1 Vuln 3

SORT

1 files · page 1/1

modules/themes/model.php

AI: 1 vulnerabilities

CWE-284: Improper Access Control CVE-2024-7094

#%!d(float64=004)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-7094

Security writeup for CVE-2024-7094

✓ 1 FILE

## The Exploit

An unauthenticated attacker can call the `storeTheme()` function via the plugin's AJAX endpoint and modify WordPress site theme colors without any authorization check.

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

action=jssupportticket&jssupportticket=storeTheme&data[primary_color]=%23FF0000&data[secondary_color]=%23000000
```

The server processes this request and stores the attacker-supplied color values directly into the WordPress options table via `update_option('jsst_set_theme_colors', ...)`. An attacker observes an HTTP 200 response with no error message; the theme colors silently change across the entire site, affecting all page renders until reverted.

**Why this still matters at admin**: If the WordPress site runs a SaaS multi-tenant installation where restricted admin accounts (e.g., shop managers or tenant admins) exist, a lower-privileged admin can escalate to full site control by calling this unguarded function. Session theft of any logged-in admin account also makes this a post-authentication persistence vector — the attacker gains theme-modification rights that survive normal permission downgrades.

## What the Patch Did

**Before**
```php
function storeTheme($data) {
    $data = jssupportticket::JSST_sanitizeData($data);
    update_option('jsst_set_theme_colors', wp_json_encode($data));
```

**After**
```php
function storeTheme($data) {
    if (!current_user_can('manage_options')){
        die('Only Administrators can perform this action.');
    }
    $data = jssupportticket::JSST_sanitizeData($data);
    update_option('jsst_set_theme_colors', wp_json_encode($data));
```

The patch added a capability check using WordPress's `current_user_can('manage_options')` function before allowing the theme update. This standard WordPress API enforces that only users with the administrator role can execute the `storeTheme()` function. If the user lacks the capability, the function terminates via `die()`, preventing any further processing or option updates.

## Root Cause

**CWE-284: Improper Access Control.** The `storeTheme()` function in `modules/themes/model.php` accepted user-supplied data from the AJAX request parameter `data` without first verifying that the caller held administrative privileges. The dataflow enters via the WordPress AJAX handler dispatcher (`action=jssupportticket&jssupportticket=storeTheme`), reaches the `storeTheme($data)` function directly, and writes to `wp_option` — a privileged data store — without crossing any trust boundary that checks the caller's role. The function relied only on `JSST_sanitizeData()` to clean the input, but sanitization is not authorization. An unauthenticated user, or any authenticated user without the `manage_options` capability, could invoke this function and corrupt site-wide settings.

## Why It Works

The load-bearing line is `if (!current_user_can('manage_options'))`. Removing this line restores the bug entirely; an attacker would once again bypass authorization. The `die()` statement is the enforcement: it terminates execution before the `update_option()` call. The engineer included the `die()` message for auditability and user feedback — without it, the request would hang or return 200 silently, making detection harder. The `current_user_can()` check is WordPress's standard capability-checking API, recognized by any WordPress security reviewer; it is both load-bearing and idiomatic, making the patch immediately credible to downstream auditors.

## Hardening Checklist

- **Add capability checks to all AJAX handlers**: Wrap every function that modifies options, posts, or settings with `if (!current_user_can('manage_options')) die()` or the appropriate capability constant before any state change. Use `current_user_can()`, not custom role checks.
- **Apply WordPress nonces to state-changing AJAX calls**: Add `wp_verify_nonce($_REQUEST['_wpnonce'], 'action_name')` to defend against cross-site request forgery on authenticated admin accounts. This is a separate defense from capability checks.
- **Sanitize inputs and verify output context separately**: Never rely on `sanitize_*()` functions alone to gate access. Sanitization removes dangerous characters; it does not verify permissions. Use `sanitize_text_field()` to clean input *and* `current_user_can()` to gate the operation.
- **Audit AJAX endpoints for missing capability checks**: Grep your codebase for `add_action('wp_ajax_*')` and verify that every callback begins with a capability check. Use a static analyzer or manual review to ensure none are missed.
- **Document minimum required capabilities in function docblocks**: Write `@requires manage_options` above every admin-only function so future maintainers and auditors know the intended access level at a glance.

## References

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

CVE CVE-2024-7094

PRODUCT js-support-ticket

AFFECTED ≤ 2.8.6

FIXED IN 2.8.7

STATUS Generated

Security writeup · CVE-2024-7094

Source files · 1

modules/themes/model.php Linked

↗ NVD