Gravity SMTP Vulnerability CVE-2026-4020 Is Being Actively Exploited — Patch and Rotate Now
An unauthenticated information-disclosure flaw in the popular WordPress mailer plugin is already under active attack, putting API keys, OAuth tokens, and SMTP credentials at risk on up to 100,000 websites.
A critical-in-practice vulnerability in Gravity SMTP, the WordPress mail-routing plugin installed on approximately 100,000 sites, is being actively exploited in the wild as of June 2026.
What the Flaw Actually Does
CVE-2026-4020 carries a CVSS score of 5.3, which sounds manageable. It is not. The rating reflects a bounded disclosure — the bug exposes only what the plugin stores — but that boundary is exactly where the most sensitive data lives. Gravity SMTP holds the credentials that connect a WordPress site to its outbound mail provider: API keys for services like SendGrid, Mailgun, Amazon SES, and Postmark, plus OAuth refresh tokens for Gmail and Microsoft 365 relay accounts.
No authentication required. No user interaction required. An attacker sends a crafted request, receives a structured response full of secrets, and moves on.
The CVSS math is conservative; the operational risk is not.
Why Email Credentials Are the Real Target
Mail provider credentials are among the most reusable assets an attacker can steal. A working Amazon SES key, for example, lets an operator send bulk email under your domain's reputation. Your SPF, DKIM, and DMARC records — everything your organization built to signal trustworthiness — become the attacker's deliverability infrastructure. The compromised WordPress site stops being the victim. It becomes the weapon.
Phishing operators in particular prize this class of credential. The 2024 Verizon Data Breach Investigations Report found that stolen credentials feature in more than 77% of web application breaches. Working SMTP relay access dramatically improves phishing delivery rates because the sending domain carries genuine authentication signals, not the hallmarks of a freshly registered throwaway.
"Information disclosure flaws are graded conservatively; they get used aggressively," as the security community has observed repeatedly about this class of vulnerability.
The Exploitation Timeline
WordPress plugin vulnerabilities follow a well-worn pattern. A patch ships. Within 48 hours, automated scanners identify every unpatched install on the public internet. Opportunistic exploitation then runs for months against sites that missed the update window. Gravity SMTP's install base of roughly 100,000 is not enormous by WordPress standards, but the per-site payoff here is unusually high — working email credentials are immediately monetizable.
Active exploitation is already confirmed. That means any site that ran a vulnerable version should be treated as potentially compromised, not merely at risk. Credential theft leaves no footprint inside WordPress's own log files. The evidence, if it exists, will surface in your mail provider's sending dashboard, not in `wp-admin`.
What Failed Here — and What Defenders Should Learn
The root failure is architectural. Gravity SMTP, like many WordPress plugins, stored sensitive credentials in a location accessible through the plugin's own endpoint logic. When that endpoint logic contained an authorization check that could be bypassed — or was simply absent — the credentials became retrievable by anyone who knew the path. This is a classic case of broken access control, consistently the top vulnerability category in the OWASP Top 10.
For defenders, the lesson is that plugin inventory management is not optional hygiene. Every third-party plugin in a WordPress environment is an attack surface with its own vulnerability lifecycle. Sites that rely on automatic updates without verification are exposed during the window between patch release and successful auto-update — a gap that can stretch hours or days depending on server configuration. Manual verification of the installed version string in `wp-admin` is the only reliable check.
There is a second, less obvious failure at play: secrets management. The credentials Gravity SMTP stores should not live permanently inside the plugin's own configuration tables. Rotating keys regularly — not just after incidents — limits the damage window when a disclosure flaw appears. Organizations that last rotated their SES or SendGrid API keys during initial setup are operating with credentials that may have been sitting exposed for the entire plugin's install lifetime.
Training staff to recognize phishing emails that originate from trusted domains is especially relevant here, because the most immediate downstream harm from stolen SMTP credentials is a surge in highly convincing phishing. If your own domain is suddenly sending attacker-crafted messages, your employees and customers have no technical signal to distrust them. Security-awareness training that teaches people to verify requests through out-of-band channels — regardless of how legitimate the sending address looks — is a direct compensating control for exactly this scenario.
Immediate Remediation Steps
If Gravity SMTP is installed on any site you manage, take these steps now:
- Patch immediately. Confirm the installed version number directly in `wp-admin → Plugins`. Do not assume the auto-update queue has already run.
- Rotate all credentials the plugin has ever stored. This includes SMTP passwords, API keys for every connected provider, and any OAuth refresh tokens configured for Gmail or Microsoft 365 relay accounts. Treat them as compromised.
- Audit your mail provider's sending logs for the past 30 days. Look for unfamiliar source IPs, volume spikes outside business hours, and sending patterns inconsistent with your normal traffic.
- Review WordPress for post-compromise indicators. Newly created administrator accounts, unexpected plugin installs, and recently modified `wp-config.php` timestamps are the standard markers of follow-on access after credential theft.
- Check downstream systems. If any exposed OAuth token granted access to a mailbox rather than just relay sending, the scope expands beyond email delivery into potential mailbox access and data exposure.
The Bigger Picture
Plugin-borne credential theft is a supply-chain problem masquerading as a patch-management problem. Yes, the patch matters. But the question defenders should also be asking is: which plugins in our environment hold credentials, what credentials do they hold, and how quickly can we rotate those secrets if a plugin vulnerability is announced tomorrow?
The answer to that question determines how badly the next CVE-2026-4020-class disclosure hurts. Sites that can rotate secrets in under an hour and verify patch status in minutes have a fundamentally different risk profile than those discovering their mail provider keys through unauthorized sending reports.
For organizations wanting to assess their current training and policy posture around credential hygiene and phishing recognition, Train2Secure's standards resources map common control failures to practical awareness programs. Pricing options are available at train2secure.com/pricing for teams of all sizes.
How credential-theft incidents like this could be contained
- Maintain a live inventory of every WordPress plugin that stores third-party credentials, and assign a rotation schedule to each — not just a patch schedule.
- Train employees to distrust urgent requests arriving from familiar email domains, since stolen SMTP credentials make attacker messages appear to come from your own organization.
- Run tabletop exercises that simulate a credential-disclosure event so your team can rotate secrets, audit logs, and communicate with affected parties within a defined time window.
Train2Secure's security-awareness programs help teams recognize phishing sent through compromised legitimate infrastructure — the most common downstream harm after SMTP credential theft.
Start free — no card requiredSources & further reading
Frequently asked questions
What does CVE-2026-4020 allow an attacker to do?
It allows an unauthenticated attacker to retrieve sensitive configuration data from Gravity SMTP without logging in or requiring any user interaction. That data can include SMTP passwords, API keys for services like SendGrid or Amazon SES, and OAuth tokens for Gmail or Microsoft 365 relay accounts.
Why is a CVSS 5.3 score considered misleading for this vulnerability?
CVSS scores for information-disclosure flaws reflect the bounded scope of what is exposed, not how dangerous that data is in practice. In this case, the exposed credentials can be used to send phishing email under your domain's reputation or to access connected mailboxes — outcomes that are far more damaging than a medium-severity score implies.
How do I know if my site was already compromised before I patched?
WordPress's own logs will likely show nothing. Check your mail provider's sending dashboard — Amazon SES, SendGrid, Mailgun, or Postmark — for unfamiliar source IPs, volume anomalies, or sending activity outside normal business hours. Also audit WordPress for new admin accounts and recently modified core files.
Is rotating credentials enough if I've already patched?
Patching stops new exploitation, but it does not invalidate credentials that were already stolen. Rotation is mandatory regardless of whether you can confirm a breach. Treat any API key or OAuth token the plugin held as compromised and replace it.
