SURIQ
The scanner that triages your WordPress plugins gave this one a 5.3 and called it medium. It measured the wrong thing. CVE-2026-4020 in the Gravity SMTP plugin is an unauthenticated information disclosure bug, and the information it discloses is a working set of third-party email credentials: Amazon SES keys, Google and Zoho OAuth tokens, Mailjet and Resend secrets, returned to anyone who sends a single request with no login. The disclosure is rated medium. What gets disclosed is not.
Gravity SMTP runs on roughly 100,000 sites. Defiant's Wordfence team, which found the flaw and reported it, says it has blocked more than 17 million attempts to exploit it, with daily volume climbing through the first week of June to a peak above four million blocked requests in a single day. The plugin's maintainer shipped the fix, version 2.1.5, back in March. The quiet stretch in between is the part worth studying.
What an attacker actually pulls back
The flaw sits in one REST API route. Its permission callback, the function that decides whether a caller is allowed in, was hardcoded to approve everyone. A plain unauthenticated GET to the route it exposes, /wp-json/gravitysmtp/v1/tests/mock-data, returns everything. Hit it and the plugin returns a roughly 365 KB JSON report about itself.
The report carries two payloads. One is the prize: the live credentials for whatever email services the owner wired up, with Mailjet, Resend, Zoho, Google, and Amazon SES all named in the output. The other is reconnaissance. The same response fingerprints the host, listing its PHP build and loaded extensions, the web server and database versions, the running WordPress release, the active theme, the full plugin inventory, and even the database table names. The attacker leaves with working keys and a blueprint of where to use them.
Why "medium" is the wrong number here
CVSS scores the act of disclosure. It does not score the value of what is disclosed, because it cannot know whether an endpoint leaks a software version string or a production cloud key. Here it leaks the key. A score built to rank the mechanics of a bug will always understate one whose entire impact lives in the sensitivity of the data behind it. Read 5.3 as the floor, not the ceiling.
That gap is also why this bug sat for three months before it blew up. Defenders triage by score, so a medium gets queued behind the criticals and often never reached. Attackers know the queue works that way. A deprioritized medium on a plugin with six figures of installs is a scanning sweet spot: low enough to be ignored, common enough to be worth a mass sweep. The March patch and the June exploitation spike are not a coincidence. The window stayed open because the score told everyone it was small.
Patching does not take the keys back
Updating to 2.1.5 closes the endpoint. It does nothing about the credentials that already left. This is the part of information-disclosure response that teams skip: once a secret has been served over the wire to an unauthenticated stranger, the secret is burned, and the only fix is to rotate it. The advisory's "update now" is necessary and incomplete. If your site ran a vulnerable version while the scanning was live, assume the stored keys are in someone else's hands and replace every one.
Email keys are a bad set to lose. An attacker holding your SES or Mailjet credentials can send mail as you, from infrastructure your domain already trusts, which turns a single plugin bug into a phishing and spam platform with your sender reputation attached. We have watched this shape before with developer tooling: stolen provider keys that surface first as a usage bill, in the JetBrains plugin case, not as an alert. The cost of a leaked key is rarely the disclosure. It is everything done with the key afterward.
What to do this week
If you run Gravity SMTP, this is today's work, not next sprint:
-
Update the plugin to 2.1.5 immediately.
-
Rotate every credential stored in the plugin's email integrations: Amazon SES, Mailjet, Google, Resend, Zoho, and anything else you connected.
-
Search your access logs for requests to
gravitysmtp/v1/tests/mock-data. The path is a clean, durable signature; even after you patch, it tells you whether you leaked before you closed the hole. -
Cross-check those log hits against the published attacker IP addresses, then watch your email providers' send logs for traffic you did not generate.
The pattern here is not unique to one plugin. The WordPress plugin surface keeps producing the same failure: an endpoint that trusts the caller, a maintainer that patches quietly, and a medium score that buys the attacker months. We have covered it as an admin-only backdoor a scanner walked past, as a re-exploited account takeover, and as a hosting plugin handing out root. The defense that holds across all of them is the same: treat every plugin that stores a secret as a credential store, and answer its bugs the way you would answer a leaked password, by rotating, not just patching.
Is your site already exposed?
Any site that ran Gravity SMTP 2.1.4 or earlier during the exploitation window should be treated as probed. The attack needs no authentication and leaves a request in your access logs, so you can confirm exposure directly: look for hits on the plugin's mock-data endpoint. If you find them, the stored email keys are compromised, and patching alone will not contain it.