CVE-2026-4020: Gravity SMTP Bug Leaks Live API Keys to Anyone — 17 Million Attacks and Counting
If your WordPress site uses Gravity SMTP, your live API keys and OAuth tokens are an unauthenticated GET request away from being stolen — and they're being mass-harvested right now. CVE-2026-4020 is an information-disclosure flaw in the Gravity SMTP plugin that lets any unauthenticated visitor read the plugin's stored credentials for connected email services: Amazon SES, Gmail, Mailjet, Resend and Zoho. Wordfence has blocked over 17 million exploit attempts since early May 2026, with peak volume on 7 June — over 4 million blocked in a single day. The patch is in version 2.1.5 (released 17 March 2026), but installations that haven't updated have been hemorrhaging keys for weeks.
Do this in the next 5 minutes
- Update Gravity SMTP to version 2.1.5 or later. Plugins → Installed Plugins → Update Now.
- Rotate every email-service credential you'd configured in the plugin. Amazon SES, Gmail, Mailjet, Resend, Zoho — every API key, every OAuth token, every secret. Treat them as known compromised, because if you were on a vulnerable version any time after May 2026, they almost certainly were leaked.
- Check your email-service dashboards for sent-mail volume you don't recognise, new IAM users, new API keys, or unusual recipient patterns.
- Tighten DMARC, SPF and DKIM. Move to
p=quarantineorp=rejecton DMARC to limit the blast radius if a future leak happens — providers will reject unauthorised sends instead of letting them rot your domain reputation.
If those four are all you have time for right now, you've done the critical 80% of the response. The rest of this article is for understanding the bug, hunting for unauthorised sends, and avoiding the next one.
What is CVE-2026-4020?
CVE-2026-4020 is an unauthenticated information-disclosure vulnerability in the Gravity SMTP plugin — the official SMTP relay plugin from the Gravity Forms team, installed on more than 100,000 WordPress sites. Anyone — no login, no admin access, no API key — can call a specific plugin endpoint and walk away with the cleartext credentials configured for whichever email service the site uses to send mail.
Affected and patched versions
| Gravity SMTP version | Status | Action |
|---|---|---|
| 2.1.4 and earlier | Vulnerable | Update immediately AND rotate every email credential |
| 2.1.5 and later | Patched | Still rotate credentials if you ran a vulnerable version after May 2026 |
The headline facts:
- CVSS score: 5.3 (Wordfence) / 7.5 (NVD) — see note on the discrepancy below
- Authentication required: none
- Vulnerable through: 2.1.4
- Patched in: 2.1.5, released 17 March 2026
- Active exploitation: 17 million+ blocked attempts since early May 2026; peak 4 million+ in a single day on 7 June
- Installations: 100,000+ active
- Email services exposed: Amazon SES, Gmail / Google Workspace, Mailjet, Resend, Zoho
About the CVSS discrepancy
Wordfence rated it 5.3 (Medium). NVD rated it 7.5 (High). The disagreement is over impact: "info disclosure that modifies nothing" sounds low-severity until you remember that the information being disclosed is live credentials to systems that can send email as you, charge your AWS account, or read your inbox. NVD's score is closer to the reality of what an attacker can do with the data. For business-impact purposes, treat this as High and respond accordingly.
How the attack works
Gravity SMTP exposes an endpoint that returns the plugin's runtime configuration so the admin UI can render it. The vulnerability is that the endpoint never checks whether the request is actually authenticated. Sending the same request as a completely anonymous visitor returns the same configuration data, including the cleartext API keys, OAuth tokens, and connection secrets for every email connector the site uses.
There are no prerequisites — no form to fill in, no plugin setting that has to be enabled. If the plugin is installed at a vulnerable version, the keys are exfiltrable. The attacker doesn't even need to know what's there: scanners crawl every WordPress site for the endpoint and harvest whatever's returned.
Real-world activity, from Wordfence's blocks:
- Mass-scanning began in early May 2026 — within weeks of the patch dropping
- By mid-June, Wordfence had blocked more than 17 million exploit attempts
- The spike on 7 June 2026 alone saw over 4 million blocked requests in a single day
If you were running 2.1.4 or earlier during that window, your keys are almost certainly already in someone's loot dump.
Why a "low" CVSS bug is actually catastrophic for your business
Read this section carefully — most owners don't realise what leaked SMTP credentials enable. The attacker doesn't take over your site. They don't deface anything. They quietly walk away with the keys to:
- Amazon SES — they can now send unlimited email through your AWS account, billed to your AWS bill. The first you notice is usually the bill or AWS suspending your SES account for spam complaints.
- Gmail / Google Workspace — depending on the OAuth scope granted, they can send mail as you, and in many configurations read your mailbox.
- Mailjet, Resend, Zoho and similar relays — same story. Send as your domain, on your dime, with your domain's reputation.
And here's the kicker: emails sent through your legitimate provider with your real DKIM signature land in inboxes. When an attacker uses your stolen SES key to send 50,000 phishing emails impersonating your invoice template to your real customer list, those phishing emails arrive looking authentic, with your domain's blessing. By the time you notice, your domain is on blocklists, your real customers think you're a phishing operation, and your transactional email — order confirmations, password resets, audit notifications — starts bouncing.
That is "information disclosure" only in the most legalistic sense. In practice it is a business-ending event for an email-dependent business unless caught fast.
Who's affected?
Any WordPress site running Gravity SMTP at version 2.1.4 or earlier. That's it. There's no form requirement, no admin setting, no rare configuration — having the vulnerable plugin installed is the entire prerequisite.
The hardest-hit profile is sites that:
- Use Gravity Forms heavily — form-driven businesses, online stores using Gravity Forms checkout
- Need reliable transactional email and chose a "real" SMTP relay over the WordPress default
mail() - Integrate with Amazon SES, Mailjet, Zoho, Resend, or Gmail for outbound sending
If any of that describes you and you were on Gravity SMTP before 17 March 2026 without updating since, treat your email credentials as compromised — not "maybe compromised" — and respond accordingly.
How to check if your site is vulnerable
- Log in to your WordPress admin.
- Go to Plugins → Installed Plugins.
- Find "Gravity SMTP" in the list and check the version number.
- If it's 2.1.4 or earlier, you are vulnerable.
- If it's 2.1.5 or later, you are patched — but if you ran a vulnerable version any time since May 2026, you still need to assume your keys leaked.
If you have shell access:
wp plugin get gravitysmtp --field=version
How to fix it — right now
- Update Gravity SMTP to 2.1.5 or later. The patch is in the official release; no separate hotfix is needed.
- Rotate every email-service credential. This is non-negotiable if you were vulnerable for any window after May 2026 — your keys have been scraped. For each connected service:
- Amazon SES: revoke the IAM access key the plugin uses, create a new one with the same SES-send permissions, update Gravity SMTP. Check CloudTrail for unfamiliar API calls.
- Gmail / Google Workspace: revoke the OAuth grant in the connected account's security settings (myaccount.google.com → Security → Third-party apps), re-authorise the plugin.
- Mailjet / Resend / Zoho: regenerate the API key in the provider dashboard, paste the new one into Gravity SMTP.
- Reduce IAM scope on the way back in. If your SES key was full-account, make the replacement scoped to only
ses:SendRawEmailon a specificfromAddress. The next leak hurts less if the key can't do more than send mail from the one address you actually use. - Check sent-mail volume for the last six weeks on each connected provider. Look for spikes that don't line up with your business volume, recipients you don't recognise, or sends originating from IPs that aren't your hosting.
- Tighten DMARC. Move to
p=quarantineat minimum,p=rejectif your legitimate mail is well-aligned. This limits the blast radius the next time a credential leaks — providers will reject unauthorised sends instead of blackholing your whole domain reputation.
Signs your keys may already be in someone's loot dump
If you were on a vulnerable version after early May 2026, work through these as a forensic checklist. Several of the indicators will only show up days or weeks after the keys were taken, so don't assume "no signs yet" means you're clean.
- Unfamiliar outbound mail in your email provider's dashboard. AWS SES → Sending Statistics. Mailjet, Resend, Zoho → equivalent activity report. Look for unexplained volume, especially over weekends or outside business hours.
- Spam-complaint or bounce-rate spikes. Even a few hours of attacker-driven phishing through your account will hammer your bounce rate. Check Amazon SES's reputation dashboard.
-
New IAM users, access keys, or roles in AWS created on or after the suspect window:
aws iam list-access-keys --user-name <plugin-iam-user> aws iam list-users --query 'Users[?CreateDate>`2026-05-01`]' - Inbox rules and OAuth grants you don't recognise in Gmail / Workspace. Gmail → Settings → Filters and Blocked Addresses, plus myaccount.google.com → Security → Third-party apps with account access.
-
Your domain showing up on email blocklists. Test at
mxtoolbox.com/blacklists.aspxand equivalent tools. - Reports from customers about emails "from you" they didn't expect — invoices, password reset prompts, urgent action notices. This is often the first external signal of an active attack run.
If any of those check out, do not waste time on partial cleanup. Rotate every credential immediately. Notify the email providers' abuse teams — AWS Trust & Safety, Google Abuse — they accelerate reputation recovery if you self-report quickly. Contact every customer who may have received fraudulent mail. Consider rotating your DKIM keys to invalidate previously signed messages. Then have someone whose day job is incident response audit the install before declaring it clean.
Why this keeps happening
The pattern this CVE represents is one of the most common ways small businesses get hit indirectly: not a takeover of the site, but a quiet credential theft that turns the site into a launching pad against the business's other systems. Stolen SMTP keys, stolen Stripe webhook secrets, stolen analytics tokens — the modern WordPress ecosystem has hundreds of plugins each storing credentials for something important, and the supply chain is only as strong as the worst-maintained plugin among them.
For a managed site, an advisory like this is a notification at 09:00 the morning of disclosure: update applied within hours, every connected credential rotated by lunchtime, and an audit of the connected services for misuse closes out the ticket by the next day. For an unmanaged site, it's the patch sitting unapplied for three months while bots quietly drain credentials in the background — only noticed when AWS suspends the account or customers start complaining about phishing.
The fix isn't paranoia. It's having someone — yourself, your dev team, or a provider — who watches Wordfence, Patchstack and WPScan; who treats "critical CVE in a plugin we use" as a notification they act on the same day; and who has a credential-rotation runbook that doesn't require figuring it out under pressure.
Frequently asked questions
The CVSS is only 5.3 — do I really need to rotate everything?
Yes. CVSS scores categorise technical impact, not business impact. A 5.3 information-disclosure bug that leaks the keys to your email-sending infrastructure has a business impact equivalent to a Critical takeover — your domain reputation, your AWS bill, and your customer trust are all on the line. NVD's 7.5 rating is closer to that operational reality. Rotate everything.
What's the patched version of Gravity SMTP?
2.1.5, released 17 March 2026. Any version 2.1.5 or later contains the fix. But updating alone is not sufficient — you must also rotate every credential that was stored in the plugin during the vulnerable window.
How do I know if my keys were specifically targeted?
You generally won't until the attacker uses them. The exploit just reads data — it leaves no trace on your site beyond a request line in your access logs (which will be lost in the noise of normal scanning). The reliable signals come from the downstream services: unexplained mail volume, new IAM activity, customer reports of phishing. That's why "rotate even if you can't see evidence" is the right call.
Which services were exposed exactly?
Reports from the advisories specifically name Amazon SES, Gmail / Google Workspace, Mailjet, Resend, and Zoho. Any credential the plugin stored for any of those is in scope. If your installation connected to a relay not on that list, treat it as in scope anyway — the bug is in how the plugin returns configuration, not in any specific connector.
Is this being actively exploited?
Aggressively. Wordfence alone blocked more than 17 million exploit attempts between early May and mid-June 2026, with a single-day peak of over 4 million on 7 June. Treat any unpatched window after the patch dropped as a compromise window.
Why is there a CVSS scoring disagreement?
Wordfence assigned 5.3 (Medium) and NVD assigned 7.5 (High). The disagreement reflects different views of impact: Wordfence weighted the "read-only, no integrity change" attribute heavily, while NVD weighted the sensitivity of the data leaked. For business-impact response purposes, NVD's number is closer to reality.
Sources and references
Related Insights
CVE-2026-8713: Avada Builder Flaw Lets Anyone Delete Your WordPress Files (1 Million Sites at Risk)
A critical CVSS 9.1 vulnerability in the Avada Builder WordPress plugin lets unauthenticated attackers delete arbitrary files — including wp-config.php — leading to full site takeover. Roughly one million sites were exposed before the patch in version 3.15.4. Here's how it works, who's affected, exactly how to fix it, and how to check whether your site has already been hit.
10 min read
WordPress Security in 2026: The CVEs Putting Sites at Risk — and the Managed Protection That Stops Them
The WordPress CVEs hitting sites in 2026 — Ninja Forms, cPanel and NGINX — and why handing your site to a managed security company beats chasing every vulnerability yourself.
7 min read
CVE-2026-42945: 18-Year-Old NGINX Rewrite Module Flaw Puts a Third of the Web at Risk
CVE-2026-42945 — NGINX Rift — is a CVSS 9.2 heap buffer overflow undetected for 18 years. Affects every NGINX from 2008 onwards. Patches, exploit trigger, what to do tonight.
6 min read