Hackers Exploit Gravity SMTP WordPress Plugin Bug (CVE-2026-4020) to Expose API Keys

A WordPress plugin vulnerability requires API-key rotation work for affected site administrators.

BEND, OREGON — A vulnerability in Gravity SMTP, a widely used WordPress plugin that routes site email through third-party providers, is exposing the credentials those providers rely on. Disclosed on or around June 20, 2026 and tracked as CVE-2026-4020, the flaw lets an unauthenticated visitor retrieve a detailed system report — including live API keys, secrets, and OAuth tokens — by sending a single request to an exposed endpoint. The plugin runs on roughly 100,000 sites, and the security firm Wordfence says it has already blocked more than 17 million attempts to abuse the bug.

The disclosure is a vulnerability story rather than a single-site breach, but its practical weight falls on WordPress administrators. The exposed data is not abstract configuration detail; it is the working credentials for outbound mail services, which means a fixed plugin build closes the hole but does nothing for keys that may already be in the wrong hands. That pairing — patch plus credential rotation — is what turns this from a routine update into a supply-chain cleanup task for affected sites.

What Was Disclosed

The vulnerability sits in an exposed REST API endpoint. Researchers found that Gravity SMTP registered a route at "/wp-json/gravitysmtp/v1/tests/mock-data" whose permission callback unconditionally returned true — meaning the plugin performed no authentication or capability check before serving the response. Any unauthenticated visitor who reached the URL, with the query parameter "?page=gravitysmtp-settings" appended, received roughly 365 KB of JSON containing the plugin's full system report.

That report is the problem. According to the disclosure, it includes the API keys, secrets, and OAuth tokens that the plugin stores for its configured email integrations, alongside broader environment detail: SMTP credentials, the PHP and web-server versions, the list of active plugins and the active theme, database table names, and the wp-config.php constants the plugin reads at startup. In effect, a single unauthenticated request could return the live credentials for a site's outbound mail services and a map of its software stack.

The flaw is tracked as CVE-2026-4020 and carries a medium-severity CVSS score of 5.3, a rating that reporting by The Hacker News notes understates its practical impact, because the exposed material is high-value secrets rather than benign metadata. It affects every Gravity SMTP release up to and including version 2.1.4 and is resolved in version 2.1.5. The credentials most often cited as at risk belong to mainstream providers including Amazon SES, Google, Mailjet, Resend, and Zoho — the third-party services WordPress sites lean on to deliver transactional and marketing email reliably.

Defender Posture for WordPress-Site Administrators

The exploitation picture makes the posture question urgent rather than theoretical. According to the Wordfence advisory and exploitation report, the firm has blocked more than 17 million attempts against the flaw, with activity beginning in early May 2026 and spiking sharply around June 6 and 7, when it logged on the order of 4 million blocked requests in a single day. A patched plugin (version 2.1.5) is available, but the volume of automated probing means many sites running a vulnerable build will have already had their system report pulled before they updated.

The first defender task is therefore inventory and detection. Administrators should confirm which sites in their estate run Gravity SMTP and on what version, treating any installation at 2.1.4 or earlier as exposed. Because the abuse leaves a recognizable trace, teams can search web-server access logs for GET requests to "/wp-json/gravitysmtp/v1/tests/mock-data" carrying the "?page=gravitysmtp-settings" parameter; a hit on a vulnerable build is reason to assume the configured credentials were disclosed. This is the same log-driven discipline that surfaced earlier WordPress-targeting campaigns, including the ClickFix activity that abused compromised sites for malware delivery.

The second task is to widen the lens beyond the plugin itself. The exposed system report names active plugins, themes, and software versions, which gives an opportunistic actor a ready-made target list for follow-on activity even if the mail credentials were not the immediate prize. Administrators reviewing an affected site should treat the disclosure as a prompt to audit the broader install — outdated components, weak administrative access, and any secrets stored elsewhere in the configuration — rather than scoping the cleanup to Gravity SMTP alone.

API-Key Rotation Guidance

Rotation is the part of this incident that patching cannot do for you. Updating to Gravity SMTP 2.1.5 stops the endpoint from leaking, but it does not invalidate any credential that was already retrieved. For a site that ran a vulnerable version while it was reachable from the internet, the prudent assumption is that every secret in the plugin's mail configuration is compromised and must be replaced.

In practice that means working through each configured email connector and issuing new credentials at the provider, not just inside WordPress. For an Amazon SES integration, that is generating fresh access keys and retiring the old ones; for Google, Mailjet, Resend, Zoho, or any SMTP setup, it is the equivalent step of revoking the existing key, secret, or OAuth token and provisioning a replacement. Rotating only within the plugin's settings screen, without invalidating the prior credential at the provider, leaves a working key in circulation.

Rotation should also extend to the blast radius of those keys. A leaked mail-provider credential can let an outsider send mail as the organization — useful for phishing that borrows the brand's reputation and deliverability — so administrators should review provider-side sending logs for unfamiliar activity during the exposure window, tighten any over-broad API permissions while reissuing keys, and confirm that sender authentication records such as DKIM are intact. The goal is not only to cut off access but to verify the credentials were not used before they were rotated.

Open Questions

Several points remain open. The headline figures — roughly 100,000 installations and more than 17 million blocked attempts — describe scale and pressure, but they do not establish how many individual sites actually had credentials exfiltrated, which depends on whether each site was running a vulnerable build, was reachable, and was hit before patching. The most detailed account of the endpoint and the exploitation timeline traces to Wordfence; while other outlets such as BleepingComputer have reported the story, the core technical findings rest substantially on that single primary source, and independent confirmation of the scope of real-world credential theft is still developing. It is a reminder of how exposed the WordPress plugin layer remains as an attack surface.

What is confirmed is enough to act on. A medium-rated but high-impact flaw, exploitable without authentication, has been leaking live mail-provider credentials from a plugin installed on the order of 100,000 sites, a fixed version is available, and exploitation has been observed at scale. For affected administrators the sequence is settled even where the totals are not: update to 2.1.5, hunt the logs for the tell-tale request, and rotate every API key, secret, and OAuth token the plugin held — because in this case the patch and the credential rotation are two separate jobs, and only one of them is finished by an update.

The CyberSignal Analysis

The reported facts above are drawn from Wordfence's advisory and the coverage that followed; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — A Debug Endpoint Should Never Hold Live Secrets

The root cause worth dwelling on is not the missing permission check alone but what sat behind it. A system-report or mock-data route is a diagnostic convenience — the kind of endpoint plugin authors add to help support staff reproduce a customer's environment — and it had no business returning live API keys, secrets, and OAuth tokens in cleartext at all. Our reading is that the authentication miss turned a design smell into a disclosure, but the design smell was the standing hazard: a plugin that concentrates working mail-provider credentials into a single serializable report is one access-control mistake away from leaking them regardless of who is supposed to be allowed in.

For teams that build or vet WordPress plugins, the transferable lesson is to treat diagnostic surfaces as first-class attack surface. A report intended for an authenticated administrator should redact secrets by default, not rely on the permission callback as the only thing standing between a debug convenience and the public internet. Defense in depth means assuming the auth check will occasionally fail — because in this case it did, unconditionally returning true — and ensuring the payload behind it is not a bundle of live credentials when it does.

Signal 02 — Rotation, Not Patching, Is the Work That Actually Closes This

The instinct after any CVE is to update and move on, and here that instinct is a trap. Version 2.1.5 stops the endpoint from leaking, but every secret already pulled during the exposure window remains valid until it is revoked at the provider. Our assessment is that the mental model administrators should carry away from this incident is that a patch fixes the software while rotation fixes the exposure — two separate jobs, and the update finishes only the first. A site that applied 2.1.5 and considers itself remediated has, in the cases that were hit, simply left working keys in an attacker's pocket.

That reframing matters beyond this one plugin. Any vulnerability whose payoff is disclosed secrets — leaked tokens, exposed environment files, config dumps — carries the same two-part remediation, and security teams that instrument only for patch compliance will systematically under-count their real exposure. The durable practice is to tie any secret-disclosure CVE to a credential-rotation runbook by default, so the response is not remembered case by case but built into how the class of bug is handled.

Signal 03 — Disclosure Starts the Clock on Mass Scanning

The exploitation numbers tell a story about tempo. Wordfence logged activity building through early May and then spiking to on the order of four million blocked requests in a single day around June 7 — the signature of automated infrastructure racing to sweep every reachable install before defenders patch. Our reading is that the window between a disclosure and mass exploitation of a low-complexity, unauthenticated bug is now effectively zero; the moment a route like this is public, opportunistic scanning treats the entire installed base as a target list to be worked through mechanically.

For defenders the operational consequence is that patch cadence has to be measured against scanner cadence, not against a comfortable maintenance window. A bug that requires no authentication and no user interaction, against a plugin with a six-figure install count, will be probed at internet scale within days. The teams that come out ahead are the ones that can detect the tell-tale request in their logs and rotate on the assumption of compromise, rather than waiting for confirmation that their specific site was among the millions swept.

Sources