CVSS 9.8Critical

CVE-2025-11833: Post SMTP Email Log Exposure Enables Unauthenticated Account Takeover

Overview

  • CVE: CVE-2025-11833
  • Plugin: Post SMTP – WordPress SMTP Plugin
  • Affected Versions: All versions up to and including 3.6.0
  • Patched Version: 3.6.1 (released October 29, 2025; active exploitation began November 1, 2025)
  • CVSS: 9.8 (Critical)
  • Authentication: None required (unauthenticated)
  • Type: Missing Authorization / Unauthenticated Account Takeover via Email Log Access

Despite a patch being available since October 29, 2025, active exploitation of this vulnerability surged on November 1, 2025, targeting approximately 400,000 WordPress sites running the Post SMTP plugin. Wordfence blocked over 4,500 exploit attempts within the first days of the campaign.

The attack is both simple and devastating. Post SMTP logs every outbound email — including password reset links — to the database for troubleshooting purposes. A missing access control check on the REST API endpoint that serves these logs means any unauthenticated attacker can read them freely. With a valid reset link in hand, the attacker sets a new password for the administrator account and logs in. No credentials, no existing session, nothing.

What Happened

Post SMTP is a plugin that replaces WordPress's default wp_mail() function with a proper SMTP delivery mechanism. To help site owners diagnose delivery failures, the plugin records every outbound email — including recipient address, subject line, and full message body — in the WordPress database. This is the email log feature.

The root cause of the vulnerability lies in how the plugin registers its REST API routes. Inside the plugin's __construct function, REST API routes are registered for accessing these logs. However, the permission_callback parameter — the function WordPress calls to determine whether a given request is authorized — was either absent or implemented in a way that always granted access.

The vulnerable registration looked conceptually like this:

// Vulnerable code (conceptual representation)
add_action( 'rest_api_init', function () {
    register_rest_route( 'post-smtp/v1', '/logs', [
        'methods'  => 'GET',
        'callback' => [ $this, 'get_email_logs' ],
        // permission_callback is missing or unconditionally returns true
        'permission_callback' => '__return_true',
    ] );
} );

When permission_callback is set to __return_true or omitted entirely, WordPress treats the endpoint as publicly accessible. Any unauthenticated request — including from anonymous visitors and automated bots — is allowed through. The full email log, including every password reset message ever generated by the site, becomes publicly readable via a simple GET request.

How the Attack Works

The attack chain is fully automatable and requires almost no technical sophistication. It exploits two legitimate WordPress mechanisms: the built-in password reset flow and Post SMTP's diagnostic logging.

  1. Identify a target site: Find a WordPress site running Post SMTP 3.6.0 or earlier. Version information can be retrieved using WPScan, similar tooling, or a scanner like Nyambush.

  2. Enumerate the administrator account: WordPress exposes usernames through author archive URLs by default. A request to /?author=1 typically redirects to /author/admin/ or similar, revealing the login name. The REST API endpoint wp-json/wp/v2/users may also return user data if not restricted.

  3. Trigger a password reset for the administrator: Submit a standard WordPress lost-password request targeting the admin account.

POST /wp-login.php?action=lostpassword
user_login=admin

WordPress generates a time-limited reset key, constructs a reset URL, and delivers it to the administrator's email address. Post SMTP logs the full message body — including the reset link — to the database.

  1. Read the reset link from the email log without authentication: Call the Post SMTP REST API endpoint to retrieve the full log.
GET /wp-json/post-smtp/v1/logs

The response returns logged emails as structured data:

[
  {
    "id": 42,
    "subject": "[Example Site] Password Reset",
    "to": "[email protected]",
    "body": "...Someone has requested a password reset for the following account...\n\nTo reset your password, visit the following address:\nhttps://example.com/wp-login.php?action=rp&key=AbCdEfGhIjKlMnOpQrSt&login=admin...",
    "created_at": "2025-11-02 03:14:15"
  }
]
  1. Use the reset link to set a new password: Navigate to the extracted URL and choose a new password. Because the link was generated by WordPress's legitimate reset mechanism, it is accepted as a valid reset operation without any further verification.
GET /wp-login.php?action=rp&key=AbCdEfGhIjKlMnOpQrSt&login=admin
  1. Log in as the administrator and take full control: Authenticate with the newly set password. From this point, the attacker has unrestricted access to the WordPress admin panel, the database, and the underlying server through plugin or theme code execution.

The entire attack requires zero prior knowledge of the site's credentials. It works by combining a legitimate WordPress feature (password reset) with a broken access control on a diagnostic endpoint.

Real-World Impact

  • Approximately 400,000 sites are potentially affected
  • Wordfence documented more than 4,500 exploit attempts in the first few days following public disclosure
  • No authentication is required, making automated large-scale scanning and exploitation trivial
  • Full administrator account takeover allows attackers to install backdoor plugins, deface content, exfiltrate data, and establish persistent access
  • The email log exposes more than just reset links. Contact form submissions, new user registration notifications, and any other system emails sent through the plugin are also readable, constituting a broad information disclosure alongside the account takeover
  • Only three days elapsed between the release of the patch (October 29) and the start of active exploitation (November 1). Sites running automated update cycles longer than a few days had a meaningful exposure window with no protection

Fix and Lessons

Fix: Patched in version 3.6.1, released October 29, 2025. The fix introduces a proper permission_callback on the email log REST API routes, requiring the requesting user to hold the manage_options capability (or equivalent administrator-level permission). Unauthenticated requests are now rejected with a 401 response. All sites running Post SMTP should update immediately.

Lessons:

  1. REST API endpoints require explicit permission callbacks: Registering a WordPress REST API route without a permission_callback, or with one that unconditionally returns true, is equivalent to publishing that endpoint on the open internet. Even read-only endpoints must have authorization checks when they return sensitive data.
  2. Treat diagnostic logs as sensitive data: Debugging and logging features exist to help developers diagnose problems, but in a production environment they frequently capture data that must not be exposed externally — email bodies, reset tokens, API keys, and credentials. Access to diagnostic logs must be gated behind administrator authentication.
  3. Patch velocity must match exploit velocity: This case demonstrates that the window between patch release and widespread exploitation can be measured in days, not weeks. Monthly or even weekly update cycles are insufficient for Critical vulnerabilities. A risk-based patching policy that triggers immediate review for CVSS 9.0+ findings is essential.
  4. Password reset infrastructure is a high-value attack surface: Any component in the password reset pipeline — email delivery, log storage, token management — is a potential attack vector. A flaw in any one of them can render the entire authentication mechanism irrelevant.
  5. Continuous plugin inventory and alerting: With 400,000 active installs, many site owners had no awareness that a critical vulnerability existed in their stack. Maintaining a live inventory of installed plugins and their versions, coupled with automated CVE alerting, is the only reliable way to close this gap before attackers exploit it.

Detection with Nyambush

Nyambush automatically detects installed WordPress plugin versions and cross-references them against its vulnerability database. When Post SMTP version 3.6.0 or earlier is detected on a site, Nyambush immediately raises a Critical alert with CVSS 9.8.

Beyond version detection, Nyambush actively probes the Post SMTP email log endpoint (/wp-json/post-smtp/v1/logs) to confirm whether it is reachable without authentication. If the endpoint returns log data to an unauthenticated request, Nyambush confirms the vulnerability is actively exploitable — not merely theoretically present — and escalates the severity accordingly. In continuous monitoring mode, the alert persists until the plugin is updated to version 3.6.1 or later, at which point Nyambush automatically verifies the fix and clears the finding.

Share this article:Post on X

Is your domain secure?

Run a free scan with Nyambush to check your security risks right now.