Exploitation Research Plan: CVE-2026-24384 (Merge + Minify + Refresh CSRF)

1. Vulnerability Summary

The Merge + Minify + Refresh plugin (up to version 2.14) is vulnerable to Cross-Site Request Forgery (CSRF). The vulnerability exists because the plugin registers a function to handle cache purging or settings updates via the admin_init or admin_post hooks without implementing proper nonce validation (e.g., check_admin_referer). This allows an unauthenticated attacker to trick a logged-in administrator into triggering administrative actions, such as clearing the plugin's optimization cache, by visiting a malicious link.

2. Attack Vector Analysis

• Endpoint: /wp-admin/index.php or any admin page (triggered via admin_init).
• Hook: admin_init.
• Vulnerable Function: Likely purge_cache() or a similar administrative action handler.
• HTTP Parameter: mmr_purge (inferred from common plugin patterns and version 2.14 logic).
• Authentication Level: Administrator (victim must be logged in).
• Preconditions: The plugin must be active.

3. Code Flow

1. The plugin initializes and registers a method (e.g., purge_cache) to the admin_init hook.
2. When any admin page is loaded, the admin_init hook fires.
3. The vulnerable function checks for the presence of a specific GET parameter (e.g., $_GET['mmr_purge']).
4. If the parameter is present, the function proceeds to delete files in the cache directory (wp-content/cache/mmr/).
5. Vulnerability: The function fails to call check_admin_referer() or wp_verify_nonce() before performing the file deletions.

4. Nonce Acquisition Strategy

This vulnerability is characterized by missing nonce validation. Therefore, no nonce is required to exploit the vulnerability. The goal of the CSRF is to trigger the action using the administrator's existing session without providing a valid security token.

5. Exploitation Strategy

The goal is to trigger the cache purge action remotely via the administrator's browser.

Step-by-Step Plan:

1. Identify the Trigger: Verify the exact GET parameter used for purging. Based on version 2.14, it is likely mmr_purge.
2. Determine the Cache Directory: Confirm the location of the cached files (usually wp-content/cache/mmr/).
3. Populate Cache: Visit the site frontend as an anonymous user to ensure the plugin generates some merged/minified files.
4. Execute CSRF: Use the http_request tool to simulate the administrator's browser sending a GET request to the purge endpoint.

Exploit Request (Simulated via Admin Session):

GET /wp-admin/index.php?mmr_purge=1 HTTP/1.1
Host: localhost:8080
Cookie: [Admin Session Cookies]

Payload Details:

• Method: GET
• URL: http://localhost:8080/wp-admin/index.php?mmr_purge=1
• Expected Outcome: The plugin deletes all files in the MMR cache directory.

6. Test Data Setup

1. Install Plugin: Install Merge + Minify + Refresh version 2.14.
2. Enable Optimization: Ensure JS/CSS merging is enabled in the plugin settings.
3. Generate Cache:
   • Use browser_navigate to visit the homepage: http://localhost:8080/.
   • Verify files exist in the cache: ls -la /var/www/html/wp-content/cache/mmr/.
4. Create Admin User: Ensure a standard administrator user exists for the session context.

7. Expected Results

1. Before the request, /wp-content/cache/mmr/ should contain several .js and .css files.
2. After the administrator (simulated by the agent) sends the request with ?mmr_purge=1, the response should typically redirect back to the admin dashboard or show a success message.
3. The directory /wp-content/cache/mmr/ should now be empty or significantly cleared of files.

8. Verification Steps

After performing the exploit with the http_request tool:

1. Check Filesystem:

   wp eval 'echo count(glob(WP_CONTENT_DIR . "/cache/mmr/*"));'
   

   A result of 0 (or a lower count than before) indicates the purge was successful.
2. Check Plugin Options (if applicable): Check if any "last purge" timestamp option was updated in the database.

   wp option get mmr_last_purge (inferred)
   

9. Alternative Approaches

If mmr_purge via GET does not work, investigate:

• POST-based actions: Check if the purge or settings save requires a POST request to admin-post.php with action=mmr_save_settings.
• Different Parameters: Check for action=mmr_refresh or mmr_flush.
• AJAX Endpoint: Search for wp_ajax_mmr_ hooks. If an AJAX handler like wp_ajax_mmr_purge exists without check_ajax_referer, it can be exploited via a CSRF POST request to /wp-admin/admin-ajax.php.

Alternative POC (POST AJAX):

// To be executed via browser_eval in an admin context
fetch('/wp-admin/admin-ajax.php', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: 'action=mmr_purge_cache' // (inferred action name)
});