ANALYSIS · 7613d41a· FINISHED 2026-06-13 · PATCHDIFF

w3-total-cache2.8.1 → 2.8.2✓ COMPLETED

Files119

Vulnerable50

True positives0

CVE matched4

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

CVE-2024-12365

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 119 CVE 4 Vuln 50

SORT

4 files · page 1/1

Extension_ImageService_Plugin_Admin.php

AI: 2 vulnerabilities

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

#%!d(float64=027)

Generic_Plugin_Admin.php

AI: 3 vulnerabilities

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

#%!d(float64=042)

inc/options/common/footer.php

AI: 1 vulnerabilities

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

#%!d(float64=071)

vendor/composer/installed.php

No vulnerability

CVE-2024-12365

#%!d(float64=116)

1–4 of 4

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-12365

Security writeup for CVE-2024-12365

✓ 4 FILES

## The Exploit

An authenticated WordPress user with Subscriber-level access can invoke W3 Total Cache admin functionality, generate a valid plugin nonce, and trigger arbitrary admin actions without holding the `manage_options` capability.

```bash
# Attacker logs in as a Subscriber
# Then visits the W3TC admin page to trigger the vulnerable hook

curl -b "wordpress_logged_in=<subscriber_session>" \
  "https://target.wordpress.local/wp-admin/admin.php?page=w3tc" \
  -H "User-Agent: Mozilla/5.0"

# The response includes:
# 1. A valid W3TC nonce rendered in the footer (CWE-284 violation)
# 2. Access to the top navigation bar showing admin settings
# 3. Ability to craft requests using the nonce to:
#    - Consume service plan limits
#    - Make arbitrary HTTP requests to internal services
#    - Query cloud instance metadata (on AWS/GCP/Azure deployments)
```

When the request lands, the attacker observes the full W3TC admin UI with a generated nonce value embedded in the page source — specifically in the footer's "Learn more about Pro!" button element: `{nonce: '...' }`. Using this nonce, the attacker can now craft POST requests to W3TC AJAX handlers that check only nonce validity, not the user's capability level, to perform actions reserved for administrators.

## What the Patch Did

**Before:**
```php
public function admin_init() {
    // Special handling for deactivation link, it's plugins.php file.
    if ( 'w3tc_deactivate_plugin' === Util_Request::get_string( 'action' ) ) {
```

**After:**
```php
public function admin_init() {
    if ( ! \user_can( \get_current_user_id(), 'manage_options' ) ) {
        return;
    }

// Special handling for deactivation link, it's plugins.php file.
    if ( 'w3tc_deactivate_plugin' === Util_Request::get_string( 'action' ) ) {
```

The patch added explicit capability checks using WordPress's `current_user_can( 'manage_options' )` API at the entry point of eight WordPress admin hooks: `admin_init`, `admin_enqueue_scripts`, `admin_head`, `admin_print_styles`, `admin_print_scripts`, `load_plugins_page_js`, `admin_notices`, and specialized handlers like `top_nav_bar()`, `admin_footer()`, and `admin_menu()`. These hooks fire for all authenticated users in the WordPress admin backend, not just administrators. The fix ensures that only users with the `manage_options` capability — typically site administrators — can proceed into the handler logic that renders UI, generates nonces, and enqueues scripts.

## Root Cause

**CWE-284: Improper Access Control.** The vulnerability flows as follows: when any authenticated user navigates to `/wp-admin/`, WordPress fires the `admin_init` hook for all users. The W3TC plugin's `Generic_Plugin_Admin::admin_init()` method listens on this hook but lacked a capability check at its entry point. The attacker-controlled request parameter is the page itself (`page=w3tc` in the URL), which is read by `Util_Request::get_string()` to determine which W3TC page to display. Before the patch, this parameter was processed without verifying `current_user_can( 'manage_options' )`. Further downstream, the footer renderer (`inc/options/common/footer.php`, line 48) invoked `wp_create_nonce( 'w3tc' )` unconditionally, generating a valid CSRF token that a Subscriber could reuse in cross-site requests to W3TC AJAX endpoints. The trust boundary crossed: unauthenticated *intent* (URL parameter) was trusted as administrative *authority* (capability).

## Why It Works

The load-bearing line is `if ( ! \user_can( \get_current_user_id(), 'manage_options' ) ) { return; }` inserted at the start of `admin_init()`. Without this line, all downstream code in the method runs for any authenticated user. The subsequent checks — the same guards added to `top_nav_bar()`, `admin_enqueue_scripts()`, and `admin_footer()` — are defence-in-depth layers that catch different pathways: a Subscriber who somehow bypasses the `admin_init()` guard might still render the footer UI, and the footer check prevents nonce generation. But the `admin_init()` check is critical because it gates the entire admin initialization pipeline. If removed, a Subscriber could re-enable the vulnerability even with the other guards in place, because the admin hooks themselves would continue to fire and enqueue scripts, render navigation, and call downstream functions. The other eight hooks needed the same treatment because WordPress calls them independently; a Subscriber could visit `/wp-admin/` and trigger `admin_enqueue_scripts` without triggering `admin_init` under certain conditions (plugin load order, hook timing). The engineer correctly identified that capability checks must sit at *every* WordPress admin hook that W3TC listens to, not just the primary one.

## Hardening Checklist

- Add `if ( ! current_user_can( 'manage_options' ) ) return;` at the entry point of *every* function hooked to `admin_*` actions (not just `admin_init`). WordPress fires these hooks for all authenticated users; UI-level protection via `add_menu_page()` capability parameters is insufficient.
- Use `wp_verify_nonce()` on all AJAX handlers and form submissions, *and* pair it with `current_user_can()` checks. A valid nonce proves intent, not authority.
- Audit all calls to `wp_create_nonce()` — ensure they are surrounded by capability checks that prevent lower-privileged users from reaching the nonce generation code in the first place.
- Conduct a grep audit for functions hooked to WordPress admin hooks (e.g., `add_action( 'admin_init', ... )`) and verify each callback has a capability check as its first statement.
- For multi-role plugins, use role-specific capabilities (e.g., `edit_posts`, `upload_files`) rather than only `manage_options`. The `Extension_ImageService_Plugin_Admin` diff shows the right pattern: use `upload_files` for media-related features, allowing Editors and Authors to access image settings without full admin rights.

## References

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

CVE CVE-2024-12365

PRODUCT w3-total-cache

AFFECTED ≤ 2.8.1

FIXED IN 2.8.2

STATUS Generated

Security writeup · CVE-2024-12365

Source files · 4

Extension_ImageService_Plugin_Admin.php Linked

Generic_Plugin_Admin.php Linked

inc/options/common/footer.php Linked

vendor/composer/installed.php Linked

↗ NVD