Gravity SMTP Vulnerability Exploited: Secure Your WordPress API Keys Now

In the highly dynamic world of WordPress security, the line between minor configuration oversight and full-blown infrastructure compromise is incredibly thin. A stark reminder of this reality arrived as security researchers and site owners witnessed an aggressive global exploit blitz targeting a newly disclosed Gravity SMTP vulnerability (tracked as CVE-2026-4020). Originally designed by RocketGenius to streamline and secure transactional email routing, Gravity SMTP has found its way onto more than 100,000 active websites. However, a major oversight in the plugin’s REST API layer has transformed this helpful utility into a goldmine for malicious actors looking to harvest high-value API keys, OAuth tokens, and detailed server blueprints.

While WordPress REST API flaws are a perennial thorn in the side of security teams, this particular breach is notable for exposing actual integration credentials to external messaging giants. In this deep dive, we will dissect the mechanical root cause of this vulnerability, examine the telemetry of the global exploit campaigns, trace the real-world operational fallout of credential theft, and outline a robust blueprint for mitigation and incident response.

The Technical Mechanics of the Gravity SMTP Vulnerability

To understand the root cause of CVE-2026-4020, we must look at how the WordPress REST API manages routing and permissions. WordPress provides developers with a robust function called register_rest_route(), which maps URLs to internal PHP methods. Security on these endpoints is handled through a critical parameter named permission_callback. This callback acts as a gateway; it must return a boolean true to grant access to the requested data, or a WP_Error if the user fails authorization checks (such as verifying a nonce or checking if the user has administrator privileges).

The core of the Gravity SMTP vulnerability lies in a shared utility library deployed by RocketGenius across some of its products, designed to collect and localized settings for modern JavaScript interfaces. Within this configuration framework, the plugin registered a dedicated REST API endpoint at the following path:

/wp-json/gravitysmtp/v1/tests/mock-data

For reasons likely related to local development, debugging, or a programming oversight, the permission_callback mapped to this endpoint was configured to unconditionally return true. Consequently, the WordPress engine skips all authentication layers. Anyone on the internet—without logging in, bypassing all cookies, nonces, or roles—can send an HTTP GET request to this URL and invoke the internal controller.

The exploit takes on a catastrophic dimension when paired with query parameters. When an attacker appends the query parameter ?page=gravitysmtp-settings, the plugin’s internal system collection logic is triggered. Specifically, the register_connector_data() method is executed, which instructs Gravity SMTP to populate its active email connector arrays. Once populated, the endpoint generates and dumps a massive, plaintext 365-kilobyte JSON payload representing the site’s complete “System Report”.

The Payload: Inside the 365 KB Server Blueprint

Because the endpoint bypasses authorization checks, an attacker receives a comprehensive snapshot of the WordPress installation and its underlying infrastructure. Far from a basic status page, the leaked 365 KB JSON file provides an unparalleled target intelligence blueprint. If scanned, the system report exposes the following crucial datasets in plaintext:

• Enterprise Email API Keys & OAuth Tokens: Gravity SMTP connects WordPress to third-party delivery networks. The report exposes plaintext API credentials, secret keys, SMTP passwords, and active OAuth tokens for integrations including Amazon SES, Google Workspace/Gmail, Mailjet, Resend, and Zoho.
• Infrastructure Stack Blueprint: The JSON file leaks the exact PHP version, loaded PHP extensions, web server software and version (Nginx or Apache), and the absolute document root path of the file system.
• Database Architecture Metadata: The system report reveals the database server type and version (such as MySQL or MariaDB), along with precise database table names—including custom table prefixes, which are traditionally randomized to defend against SQL injection attacks.
• Application Attack Surface: The endpoint leaks the exact WordPress core version, active themes, and a complete directory listing of every installed plugin along with its corresponding version number.

With this detailed blueprint, attackers no longer need to guess where vulnerabilities lie. They are handed a map of which secondary plugins are installed, allowing them to target other unpatched software stacks on the exact same host.

The Avalanche: Scaling to 17 Million Exploit Attempts

Though RocketGenius quietly addressed the vulnerability in Gravity SMTP version 2.1.5 in mid-March 2026, the real-world crisis escalated months later. This delay is typical of reverse-engineered patches; once threat actors noticed the altered REST API permission logic in updated source files, they immediately began crafting mass-scanning tools.

According to telemetry released by cybersecurity firm Defiant, the operators of Wordfence, the campaign exploded in early May 2026. Since then, Wordfence has logged and blocked over 17 million exploit attempts targeting CVE-2026-4020. The attack reached a fever pitch during a coordinated global blitz starting on June 7, 2026, peaking at more than 4 million malicious requests in a single 24-hour window.

The threat intelligence platform CrowdSec further corroborated this surge, noting that by late May and early June, the vulnerability had entered the “background noise” phase of the internet. This industry term describes the state when a vulnerability is fully integrated into automated, global botnet scanning arrays. Rather than targeted, manual attacks, compromised and malicious IP addresses now crawl the web constantly, checking every WordPress site they find for the `/tests/mock-data` path.

CrowdSec’s telemetry revealed that the target mix is highly business-relevant. Approximately 55% of observed victims fall within commerce and transactional environments, while 39% are SOHO (small office and home office) setups. These target environments are particularly attractive because they depend heavily on operational transactional mail and are highly likely to have valid billing profiles tied to their external SMTP accounts.

The Downstream Fallout: A Real-World Case Study

While the Gravity SMTP vulnerability does not directly provide Remote Code Execution (RCE) on the local host, the downstream operational consequences are devastating. To appreciate how this vulnerability manifests on a business level, one must look at the real-world experiences of affected hosting providers and administrators.

For instance, Anchor Hosting documented a relentless cycle of Mailgun account suspensions occurring throughout May and June 2026. The administrator reported that their centralized Mailgun accounts—used to host mail domains for dozens of clients—were repeatedly locked by Mailgun’s compliance team. Investigations eventually revealed that postmaster verification connection tests and malicious email campaigns were being funneled from a host IP in Germany (specifically 94.26.106.248).

The attackers had scanned their clients’ WordPress sites, discovered vulnerable Gravity SMTP instances, and harvested the unique Mailgun API keys and SMTP credentials stored within the databases. By using these stolen keys, the hackers bypassed local server security entirely. They connected directly to Mailgun’s SMTP endpoints to send massive phishing runs under the clients’ legitimate domains. The primary impacts of this attack path include:

1. Unbounded Financial Costs: High-volume cloud mail networks charge per email or based on data tiers. Hijacked keys allow attackers to send millions of emails, racking up massive bills charged directly to the victim’s credit card.
2. Total Domain Reputation Ruin: Because the phishing emails originate from legitimate domains with correct SPF, DKIM, and DMARC records, the victim’s domain reputation is instantly destroyed, leading to immediate blacklisting across global spam databases.
3. Upstream Account Suspensions: Service providers like Mailgun, Amazon SES, and Google Workspace are quick to lock accounts displaying suspicious behavior, instantly breaking legitimate business notifications, invoice deliveries, and sign-up flows.

Incident Response & Actionable Remediation Blueprint

If you or your clients run Gravity SMTP, you must assume a proactive defense posture. Merely updating the plugin is insufficient if the site has already been audited by automated scanners, as the keys are likely already in malicious databases. Follow this comprehensive remediation strategy immediately:

Step 1: Apply the Plugin Patch

Ensure that Gravity SMTP is upgraded to version 2.1.5 or higher. The patched version changes the REST API registration by replacing the unconditional __return_true statement with an active authorization callback that checks user capabilities, completely blocking unauthorized access to the system data.

Step 2: Rotate All Connected SMTP Credentials (Mandatory)

If your server access logs indicate a vulnerability window, or if you were running version 2.1.4 or lower during the active exploitation wave, you must treat all stored SMTP secrets as compromised. Log into your external mail providers and perform the following actions:

• Revoke all existing API keys used for the integration.
• Generate brand new keys, restricting their permissions exclusively to mail-sending roles (avoid using root accounts with administrative access).
• For OAuth-based integrations (like Google Workspace or Microsoft 365), de-authorize the existing connection within your enterprise console and re-authenticate to generate fresh tokens.

Step 3: Audit Web Server Access Logs

To determine if you have been targeted, inspect your web server’s raw access logs. Search for HTTP requests that query the specific endpoint. You can use a simple grep command in your server terminal:

grep "gravitysmtp/v1/tests/mock-data" /var/log/nginx/access.log

Pay close attention to any requests returning an HTTP status code of 200. Payloads that resulted in a 200 OK response with a large data transfer size (typically ~365 KB) are clear evidence that your credentials and system reports were successfully extracted by the visiting IP address.

Step 4: Establish Web Application Firewall (WAF) Protections

Ensure your WordPress firewall (such as Wordfence or a network-edge provider like Cloudflare) has active rules to drop any traffic targeting the mock-data endpoint. Implementing an edge-level block ensures that malicious scans are dropped long before they hit the PHP execution thread, preserving server resources during mass exploit waves.