Gravity SMTP Flaw Has Handed Attackers 17 Million Shots at Your Email API Keys

A vulnerability in the Gravity SMTP WordPress plugin has attracted over 17 million exploit attempts since late May — and the count keeps climbing. CVE-2026-4020 is officially classified as an "information disclosure" flaw, but that label undersells what actually gets disclosed: live API keys and OAuth tokens for every email service provider connected to the plugin. Patch or not, if the endpoint was open while attackers were scanning, those credentials are already circulating.

One Endpoint, No Login Required

Gravity SMTP is a standalone transactional email plugin from RocketGenius — the company behind Gravity Forms. It handles SMTP routing for WordPress sites and supports direct integrations with Amazon SES, Google Workspace, Mailjet, Resend, Zoho, and others. The plugin has approximately 100,000 active installations, concentrated among agencies, professional developers, and organizations running high email volume on the Gravity Forms stack.

The vulnerability is straightforward to the point of embarrassment. A diagnostic REST API endpoint used by the plugin's built-in testing tool:

had a permission callback that unconditionally returned true. WordPress dutifully handed over the response to any HTTP request, authenticated or not. A single GET request returned roughly 365 KB of configuration data — PHP version, web server details, database version, WordPress version, every installed plugin and theme with version numbers, database table names, and the full API credentials for every email integration configured in the plugin.

Why "Information Disclosure" Misses the Point

NIST rates CVE-2026-4020 at CVSS 7.5 HIGH; some vendors initially scored it 5.3 MEDIUM based on the narrow information-disclosure classification. The lower score misses the downstream blast radius.

Stolen API keys are not a website problem — they are a services problem. A compromised Amazon SES key doesn't just let an attacker read your email; it lets them send email as your domain, from your trusted sending identity, to whoever they choose. That means phishing campaigns that pass SPF and DKIM checks, SES bills that can run into the hundreds or thousands of dollars before you notice, and potential domain blacklisting that outlasts the original incident by weeks. A stolen Google OAuth token opens access to the connected Google account. Mailjet and Resend credentials hand over a warmed-up sending reputation to burn.

The reconnaissance data bundled in the same endpoint response is a free bonus for an attacker planning a follow-up. Knowing your exact WordPress version, full plugin inventory, and database structure makes targeted exploitation substantially cheaper to execute.

The Attack Timeline

The patch — Gravity SMTP 2.1.5 — shipped on March 25, 2026. The CVE was publicly disclosed six days later on March 31. Then came two months of quiet. First wild exploitation was recorded May 27, 2026. Volume escalated sharply in early June, peaking at over 4 million blocked requests in a single day on June 7. Wordfence has blocked more than 17 million attempts across the campaign, originating primarily from cloud and hosting infrastructure in France, the Netherlands, and the United States.

The two-month gap between patch and mass exploitation is a recurring pattern: someone pulls the CVE into a commodity scanner list, automated tools fan out, and the sites that haven't patched discover why the window matters. CrowdSec observed 412 distinct attacking IP addresses in the first week of wild exploitation alone. The attack intent in 83% of observed cases was infrastructure takeover — not reconnaissance, not defacement. These scanners are harvesting credentials to use.

Checking Your Exposure

The endpoint returns data silently on a successful hit. There is no failed login attempt to alert on, no unusual authentication event in WordPress — nothing in the logs except an ordinary-looking HTTP GET request. This means you cannot know with certainty whether you were hit unless you search for it.

Check your web server access logs for requests to /wp-json/gravitysmtp/v1/tests/mock-data. Any hit from an unknown IP before you patched confirms exposure. Cross-reference against your email service provider logs: Amazon SES sending activity, Gmail connected-apps access, Mailjet API usage. Look for sends you didn't initiate or access from unfamiliar locations.

What to Do Right Now

• Update to Gravity SMTP 2.1.5 or later. Log in to your Gravity Forms account, download the latest release, and update. This closes the endpoint. If you are on an auto-update schedule, verify the update has actually applied — the gap between "available" and "installed" is where sites get caught.
• Rotate every API key and OAuth token in the plugin's settings. Check Amazon SES, Google, Mailjet, Resend, Zoho, and any other connected provider. Revoke the existing credentials and issue new ones. Do not skip this step because you already patched — if attackers hit the endpoint while it was open, the credentials they collected are still valid and still working.
• Scope your credentials going forward. Amazon SES supports per-application IAM credentials with send-only permissions. Mailjet lets you create API keys scoped to specific operations. Most transactional email providers offer similar controls that are easy to set up and easy to skip during initial configuration. Short-lived, minimally-scoped keys limit the damage from any future disclosure.
• Add endpoint monitoring to your WAF or log alerts. If you have a WAF in front of WordPress — whether at the server level or through a service — block external access to the /wp-json/ namespace for any endpoint that doesn't need to be publicly reachable. Many WordPress sites expose far more of their REST API than their actual functionality requires.

The broader pattern here is one our team encounters consistently: API credentials for email infrastructure get provisioned at setup, handed broad permissions to avoid friction, and then left alone until something goes wrong. CVE-2026-4020 is a reminder that a single misconfigured permission callback is enough to turn that neglect into an active incident — and that "information disclosure" vulnerabilities deserve the same urgency as remote code execution when what they disclose is the keys to your outbound email.