Account Takeover Vulnerability Affecting Over 400K Installations Patched in Post SMTP Plugin

Post SMTP

Subscriber+ Account Takeover

400K

CVSS 8.8

This blog post is about a Subscriber+ account takeover (broken authentication) vulnerability in the Post SMTP plugin. If you're a Post SMTP user, please update the plugin to at least version 3.3.0.

The vulnerability in the Post SMTP plugin was originally reported by Patchstack Alliance community member Denver Jackson to the Patchstack Zero Day bug bounty program for WordPress.

About the Post SMTP plugin

The plugin Post SMTP, which has over 400,000 installations, is an email delivery plugin. It allows site owners to configure custom mailer services, and includes tooling such as email logging, DNS validation, and OAuth support to make email sending through WordPress easier. The plugin is developed by Saad Iqbal of WPExperts.

The security vulnerability

In versions 3.2.0 and below, the plugin is vulnerable to multiple Broken Access Control vulnerabilities in its REST API endpoints. These endpoints were, in the vulnerable versions, only validating that a user was logged in, not that they had the correct privileges to perform the actions. This allowed any registered user (including Subscriber-level users who should have no privileges at all) to perform a variety of actions, including: viewing email count statistics, resending emails, and most dangerously, viewing detailed email logs including the entire email body.

The ability to access this detailed information allows a Subscriber-level user to intercept any email sent by the WordPress website, including password reset emails to any user. Using this information, a low-privileged user is able to takeover an Administrator-level account, leading to a full site takeover.

The vulnerability has been patched in version 3.3.0 and is tracked with CVE-2025-24000.

The underlying vulnerability exists in the get_logs_permission function:

// TRIMMED CODE
// Patchstack note: L32-40, showing get_logs_permission as the only permission check for these REST routes
register_rest_route(
    $this->namespace,
    '/get-details',
    array(
        'methods' => WP_REST_Server::READABLE,
        'callback' => array( $this, 'get_details' ),
        'permission_callback' => array( $this, 'get_logs_permission' )
    )
);

//TRIMMED CODE
// Patchstack note: L155-163, showing no additional validation done by the REST callback
public function get_details( $request ) {
    $id              = $request->get_param( 'id' );
    $type            = $request->get_param( 'type' );
    $email_query_log = new PostmanEmailQueryLog();
    $response        = '';

    if ( 'show_transcript' === $type ) {
        $response = $email_query_log->get_log( $id, array( 'session_transcript' ) );
    }
    // remaining function code trimmed


// TRIMMED CODE
// Patchstack note: L485-492, showing the unpatched get_logs_permission function
/**
 * Get logs permission
 *
 * @return bool
 */
public function get_logs_permission() {
    return is_user_logged_in();
}

Each REST route is configured to only use the get_logs_permission function for permission checks, and no REST callback (e.g., get_details) performs additional checks. This allows any registered user to access any of the REST API calls provided by this plugin.

The patch

In version 3.3.0, the vendor patched this vulnerability by incorporating an additional privilege check in the get_logs_permission function, validating that the user has sufficient permissions to access these API calls.

This change ensures that only users with the manage_options capability (generally, only Administrator-level users) are allowed to use these API calls, resolving the broken access control vulnerabilities and, by extension, also resolving the critical account takeover vulnerability.

Conclusion

There are many reasons a user may have a login to a site: membership-only sites, eCommerce, or even just for an improved commenting experience. Not to mention the other lower privileged roles, such as Contributors who can only author content, available on a standard WordPress website. It is not enough to assume any user with a login is a privileged user, as this is often not the case. When writing plugins which allow for advanced management functionality, and especially when that functionality involves sensitive data, proper permissions checks must be performed to ensure only correctly privileged users can access this functionality.

Want to learn more about finding and fixing vulnerabilities?

Explore our Academy to master the art of finding and patching vulnerabilities within the WordPress ecosystem. Dive deep into detailed guides on various vulnerability types, from discovery tactics for researchers to robust fixes for developers. Join us and contribute to our growing knowledge base!