CVE-2026-4020: One Unlocked REST Endpoint Hands Out API Keys from 100,000 WordPress Sites — No Login Needed

In June 2026 the security world fixed on a technically silly, consequentially heavy flaw: CVE-2026-4020, in Gravity SMTP, a WordPress mailer plugin installed on roughly 100,000 sites. Wordfence rates it CVSS 5.3, but some sources (including NVD's CVSS v3.1) score it 7.5 HIGH — and that score disagreement is today's point. It lets any unauthenticated visitor send one request to a REST API endpoint and get back ~365 KB of JSON containing email service credentials, database details and the full software stack. Wordfence says it has blocked over 17 million exploitation attempts since activity began in early May 2026.

The mechanism is simple, which is exactly why it's lethal. Gravity SMTP registers a REST endpoint at /wp-json/gravitysmtp/v1/tests/mock-data whose permission_callback unconditionally returns true — "anyone gets in," with no identity check. The attack chain is absurdly short: an attacker sends a GET to that URL → the endpoint returns a full system report JSON → containing the API keys and secrets for SMTP / Mailjet / Zoho / Amazon SES / Resend connectors, database details, PHP and WordPress versions, loaded extensions, document root path, active plugins and theme. No login, no preconditions, no user interaction; the PoC is essentially "open that URL."

Affected scope: all Gravity SMTP versions through 2.1.4, ~100,000 installs. The timeline is clear too — Wordfence deployed detection on May 22, observed first real-world exploitation on May 27, and by June 1 had classified the activity as "background noise," meaning it had been folded into mass automated scanning. The patch is simple, but "patching isn't enough" is the catch — below we explain why you must do a second thing after updating.

Technical detail: vulnerability type and attack path

This is a textbook Broken Access Control plus sensitive information disclosure. WordPress's REST API uses permission_callback to decide who can call a route; the correct pattern returns a permission check (e.g. current_user_can('manage_options')). Gravity SMTP wrote it as an unconditional true on this mock-data test endpoint, exposing an internal "developer testing only" endpoint to the world. Attack complexity is minimal (one unauthenticated HTTP request), no auth, non-interactive. A harmless illustrative request looks like:

# Illustrating the attack surface only; do not run against systems you don't own
curl -s "https://victim.example/wp-json/gravitysmtp/v1/tests/mock-data" 
  -H "Accept: application/json"
# → returns ~365KB JSON with mail credentials, DB info, and the system stack

The patched 2.1.5 restores a proper permission check on this endpoint.

Immediate actions for three readers

System administrators: update Gravity SMTP to 2.1.5 or later immediately; after patching, immediately rotate all API keys, secrets and OAuth tokens configured in the plugin's connectors (they may already be leaked). Temporarily block the path /wp-json/gravitysmtp/v1/tests/mock-data at the WAF.
Developers (code level): grep all your plugins/themes for permission_callback and find any route returning return true;, replacing it with a real permission check; guard all "test/mock" endpoints behind WP_DEBUG or an env flag so they never ship to production. Nginx can simply block that path.
Agencies / consultants: inventory all WordPress sites you maintain for Gravity SMTP; send affected clients a notice (patched + keys rotated). Make "plugin asset inventory + emergency key rotation" a standard care action.

Patch vs mitigation

Situation	Immediate patch	Mitigation if you can't patch now
Can upgrade the plugin	Update to Gravity SMTP ≥ 2.1.5	—
Can't upgrade yet	—	Block `/wp-json/gravitysmtp/v1/tests/mock-data` at Nginx/WAF, or deactivate the plugin
Possibly already leaked	After upgrade, rotate all connector API keys/secrets/OAuth tokens	Same (rotation is non-negotiable)
Long term	Build a plugin asset inventory and weekly update window	Add WAF + file integrity monitoring

IOC and threat intel

Suspicious request path: GET /wp-json/gravitysmtp/v1/tests/mock-data (high volume in a short window, from varied source IPs).
Response signature: ~365 KB JSON response containing fields like api_key, secret, smtp.
Signs of downstream abuse: unexpected send volume on your SMTP/SES/Mailjet account, anomalous sending IPs, a billing spike — keys harvested and used to send spam.
How to check: grep access logs for that path and compare the first hit time against your patch time (if earlier, treat as leaked and rotate keys).

What they won't tell you

First, the score lies. Wordfence says 5.3, NVD's CVSS v3.1 says 7.5 — if you read "medium 5.3" and defer to next month, you ignore "unauthenticated, zero-interaction, 100k sites, API keys leaked directly." CVSS is a reference; exposure surface and data sensitivity are the decision. Second, "upgrade the plugin" gets treated as the finish line, but this flaw leaks credentials — patch without rotating keys and you've changed the lock while the copied key still works. The patch can't touch the key already in the attacker's hand.

The bigger trend

From first exploitation on May 27 to "background noise" by June 1 took days — the 2026 norm: the gap from disclosure to inclusion in automated scanning is compressing to days. A manual "next patch window" cadence is already obsolete against that speed. WordPress's "forgot to lock the test endpoint" isn't a one-off either; it reflects the long-standing tension between convenient internal endpoints and production safety.

FAQ

I upgraded Gravity SMTP — am I safe now?

Upgrading blocks future exploitation, but this flaw leaked API keys and credentials. If your site was scanned before patching (likely for most sites live after late May), treat those keys as leaked — rotate every mail-connector API key, secret and OAuth token configured in the plugin.

CVSS is only 5.3 — can I defer the fix?

Not advisable. 5.3 is Wordfence's score; NVD's CVSS v3.1 is 7.5 HIGH. Given "unauthenticated, zero-interaction, 100k sites, credentials leaked," the practical risk far exceeds what "medium" implies. Treat it as high priority.

I'm not sure the plugin is installed — what do I do?

Search "Gravity SMTP" in your WordPress Plugins list, or ask your maintainer for a full plugin asset inventory. Also grep access logs for /wp-json/gravitysmtp/v1/tests/mock-data to see if it was hit.

What's the most likely damage after a key leak?

Most commonly your mail service (SES/Mailjet/SMTP) account gets used to blast spam or phishing, spiking your bill, ruining your sending reputation and getting your domain blacklisted. Rotating keys plus reviewing recent send volume is the way to stop the bleeding.

My take

The reflex is "upgrade fast," but for this case upgrading is only the first half. My judgment: in 2026 WordPress operations, the real capability gap isn't "how fast you patch" but "whether you can rotate the leaked credentials in the same hour you patch." Most SMBs have no plugin asset inventory, don't know which site uses which mail connector, and have no key-rotation SOP — exactly the client-care opportunity for an agency like ScriptWalker: package "plugin asset audit + emergency key rotation + incident notice template" as a fixed action in a monthly care plan. When disclosure-to-exploitation is down to days, clients aren't buying "you write well" — they're buying "are you there in that one hour when it breaks."