Gravity SMTP credential leak: how email teams should respond

Patch Gravity SMTP, rotate exposed sending credentials, and use provider logs, DMARC reports, bounces, and blocklist monitoring to check abuse.

Gravity SMTP CVE-2026-4020 is not only a WordPress plugin patch. If a site ran Gravity SMTP 2.1.4 or older with mail credentials stored, update to 2.1.5 or later, rotate those credentials, and review provider logs, DMARC aggregate reports, bounces, and blocklist signals for abuse. On June 19, 2026, the practical state is simple: the Wordfence report is already public, exploitation has reached mass scale, and configured sending credentials should be treated as exposed until your evidence says otherwise.

Gravity SMTP is a WordPress plugin that connects a site to external email delivery providers. That can include API keys, SMTP passwords, secrets, or OAuth tokens for services used to send password resets, forms, receipts, lead notifications, and other site mail. A sensitive information exposure bug in that layer has a different operational shape from a normal plugin information leak. It can put real sending authority in an attacker’s hands.

What the Gravity SMTP flaw exposed

The vulnerable path is a REST API route intended for mock data. On affected versions, a public request with the settings page parameter can return a system report containing configured mail integration credentials. Suped’s source article reports the affected versions as Gravity SMTP 2.1.4 and older, with 2.1.5 as the patched version. Wordfence also reported about 100,000 active installations, more than 17 million blocked exploit attempts, and the largest spike on June 7, 2026.

GET /wp-json/gravitysmtp/v1/tests/mock-data?page=gravitysmtp-settings
Host: affected-wordpress-site.example

The services named in the source include Amazon SES, Google, Mailjet, Resend, and Zoho. The important detail is not the brand list. It is the trust boundary. If your domain already allows one of those providers through SPF or uses DKIM signing there, stolen credentials can send mail that looks technically authenticated.

Why DMARC can show risk but not intent

DMARC means Domain-based Message Authentication, Reporting, and Conformance. It checks whether SPF or DKIM passes and aligns with the visible From domain, then lets the domain publish a policy for failed mail. SPF checks whether the sending IP is authorized for the envelope domain. DKIM checks whether the message has a valid cryptographic signature.

Those controls are necessary, but they do not know whether a campaign was approved by your team. If a stolen API key sends through a provider that is already authorized, SPF or DKIM can still align. DMARC aggregate reports may show the traffic as authenticated while the business process behind that sender is unauthorized.

That is why the response needs both security evidence and deliverability evidence. Provider logs tell you whether the credentials were used. DMARC reports show source, volume, alignment, and authentication patterns. Bounces and complaint signals show delivery impact. Blocklist monitoring shows whether abuse started to affect IP or domain reputation.

Run the response in the right order

The operational mistake is rotating credentials before the vulnerable endpoint is gone. If the site remains on Gravity SMTP 2.1.4 or older, newly created credentials can be exposed again. Patch first, then replace secrets, then validate mail.

1. Update: Install Gravity SMTP 2.1.5 or later on production, staging, and copied WordPress sites.
2. Search logs: Look for the REST route and the settings page query parameter across CDN, load balancer, web server, and application logs.
3. Rotate keys: Revoke old API keys, SMTP passwords, OAuth client secrets, and OAuth tokens where the provider supports revocation.
4. Review DMARC: Compare normal WordPress mail volume against new sources, sudden volume jumps, alignment changes, and authentication failures.

Search for both the route and the page parameter. A read-only GET request can leak secrets without changing content, creating users, or leaving an obvious WordPress admin trail.

grep -F "/wp-json/gravitysmtp/v1/tests/mock-data" access.log*
grep -F "page=gravitysmtp-settings" access.log*

Check each evidence layer before calling it clean

Start with web access logs because they show whether the endpoint was requested. Then move to mail provider logs because they show whether credentials were used after exposure. Give special attention to early June, including June 7 through June 11, 2026, because the source article identifies that period as important to exploitation activity.

Mail provider logs should answer practical questions: Were there new sender identities? Were API sends created outside normal volume? Were there new recipients, campaigns, templates, suppressed messages, SMTP logins, or OAuth activity? Were old credentials still used after you thought rotation was complete?

For the email authentication side, Suped DMARC monitoring helps turn aggregate XML reports into source-level visibility. In this incident, that means watching for new sources using the domain, volume that does not match normal WordPress behavior, and authentication patterns that changed after the exposure window.

Blocklists matter because unauthorized mail sent through a legitimate provider can still produce spam complaints, spam trap hits, hard bounces, and throttling. Blocklist monitoring gives teams one place to watch listing signals while credentials are rotated and sending patterns return to normal.

Validate the fix with a controlled send

After patching and rotating credentials, send a controlled message through the affected WordPress path. Do not stop at “the message arrived.” Inspect the headers with an email tester and confirm that SPF, DKIM, and DMARC pass as expected, and that the source shown in the headers is the one your team intends to keep.

Write down the vulnerable version, patched version, first and last suspicious request, credentials replaced, provider logs reviewed, DMARC sources checked, and blocklist checks completed. If any evidence is missing, treat the credentials as usable by an attacker and remove that risk by revoking them.

MSPs and agencies should inventory every managed WordPress site, not only the ones reporting mail failures. Staging and inactive sites are easy to miss because they often receive fewer plugin updates while still carrying live mail credentials. Production sites should come first, then staging sites with real credentials, then inactive sites with valid tokens.

What matters after the patch

The fixed plugin version closes the immediate endpoint risk, but the mail risk ends only when exposed credentials are revoked and sending evidence is reviewed. The minimum response is patch, web log search, credential rotation, provider log review, DMARC source review, bounce review, and blocklist monitoring.

For operators, the bigger lesson is that email authentication is not only DNS hygiene. SPF, DKIM, and DMARC tell you whether mail is authenticated and aligned. They do not replace credential governance, provider logging, sender inventory, or incident response. A trusted sending path can become the abuse path when a plugin leaks the key.

Reference: Read the detailed Suped article.