A Permission Check That Always Said Yes
The flaw at the center of this campaign, tracked as CVE-2026-4020, is almost embarrassingly simple. Gravity SMTP, a plugin that handles outbound email for WordPress sites, exposed a REST endpoint at /wp-json/gravitysmtp/v1/tests/mock-data. That endpoint had a permission callback, the gatekeeper function that is supposed to decide who gets in. As Wordfence put it, by way of The Hacker News, the callback unconditionally returns true, allowing any unauthenticated visitor to access it. In other words, the lock was installed but wired to open for everyone.
From there the exploitation is trivial. Appending the parameter ?page=gravitysmtp-settings to the request causes the endpoint to return a roughly 365 KB JSON system report. No login, no token, no friction. The vulnerability affects every version of Gravity SMTP up to and including 2.1.4 and is fixed in 2.1.5. With the plugin installed on around 100,000 sites, the population of exposed targets was both large and easy to enumerate, a combination attackers find irresistible.
What Leaked, and Why It Hurts
The contents of that system report are what turn a minor information disclosure into a genuine emergency. The exposed data includes API keys and tokens for major email providers: Amazon SES, Google, Mailjet, Resend and Zoho. These are live credentials that let an attacker send mail as the victim, rack up charges, and abuse the sender's hard-earned domain reputation for spam and phishing. A stolen SES key is not an abstract risk, it is a working account someone else now controls.
The report does not stop at mail credentials. It also surfaces the PHP version, database details, WordPress configuration and the list of active plugins. That is a reconnaissance dossier handed to attackers for free, mapping out exactly which additional vulnerabilities might be worth chaining next. For an adversary, one unauthenticated request returns both the keys to the email kingdom and a blueprint of the rest of the environment. Few flaws offer that much leverage from so little effort.
Exploitation at Industrial Scale
This was not a theoretical proof of concept gathering dust in a researcher's blog. Wordfence reports it blocked more than 17 million exploit attempts against the flaw, a figure that signals coordinated, automated mass scanning rather than opportunistic poking. Attackers clearly recognized the value of the leaked credentials and built tooling to harvest them across the entire installed base as quickly as possible.
The timeline shows a deliberate ramp. Activity began in early May 2026 and then spiked dramatically, exceeding 4 million requests per day around June 6 and 7. That pattern, a slow start followed by a sharp surge, often indicates that the flaw became more widely known or that a working exploit was packaged and shared among multiple actors. Either way, the volume tells site owners something important: if you were running a vulnerable version during that window, the odds that your endpoint was hit are uncomfortably high.
Why Medium Severity Is Misleading
On paper, CVE-2026-4020 carries a CVSS score of 5.3, squarely in medium territory. That number reflects the scoring system's mechanics: it is unauthenticated and easy, but it is classified as information disclosure rather than direct remote code execution. A busy security team triaging dozens of advisories might reasonably deprioritize a 5.3 in favor of the critical-rated flaws stacking up in the queue. That instinct, in this case, would be a mistake.
The disconnect is that CVSS scores the vulnerability, not the secrets it happens to expose. When the disclosed information is a set of live API keys with billing and reputational consequences, the practical impact rivals a far higher-rated bug. This is a recurring blind spot for executives who manage risk by score alone. Severity ratings are a starting point for triage, not a substitute for understanding what an attacker actually walks away with.
Assume Compromise and Rotate
Wordfence's guidance is blunt and worth heeding: owners with configured email integrations should assume compromise and rotate their credentials. That is the correct posture given how trivially the keys leaked and how aggressively the flaw was exploited. Patching to version 2.1.5 closes the hole, but it does nothing to invalidate credentials that may already be in an attacker's hands. Rotation, not patching, is the action that actually contains the damage.
The rotation should be comprehensive. Any Amazon SES, Google, Mailjet, Resend or Zoho keys configured in the plugin should be revoked and reissued, and teams should review provider logs for unauthorized sending activity during the exposure window. Updating the plugin without rotating keys is the trap here, a half-measure that feels like remediation while leaving the actual loot still valid. Treat every exposed integration as breached until proven otherwise.
The Broader Lesson on Plugin Supply Chains
Step back and this is a story about secrets sprawl and the plugin supply chain. WordPress sites accumulate dozens of plugins, each one a piece of third-party code running with significant access and each one storing whatever credentials it needs in the site's configuration. A single flaw in a single plugin, here a one-line permission callback that returned true, can expose every secret that plugin touches. The blast radius is defined not by the plugin's importance but by what it can read.
For CTOs and CIOs overseeing any CMS-based footprint, the strategic takeaway is to treat third-party plugins as part of your attack surface and to minimize the secrets they hold in plain configuration. Wherever possible, scope API keys narrowly, prefer providers that support restricted or short-lived credentials, and monitor for the kind of mass-scanning behavior that preceded this campaign. The convenience of plugins is real, but so is the systemic risk of trusting a sprawling ecosystem of code you did not write with the keys to your most sensitive services.
