Gravity SMTP flaw exposes email sending credentials during mass exploitation
News
Published 18 Jun 2026
Updated 23 Oct 2026
10 min read
Summarize with
Updated on 23 Oct 2026: We corrected the patch timeline and added containment steps for exposed mail credentials.
Gravity SMTP users running version 2.1.4 or older need to install the latest available release, then revoke and replace any configured mail sending credentials. Version 2.1.5 is the first release that fixes CVE-2026-4020. Wordfence reported mass exploitation of this unauthenticated information disclosure flaw in June 2026.
The Wordfence report published on June 17, 2026 estimated about 100,000 active plugin installations and reported more than 17 million blocked exploit attempts, including over four million on June 7. These figures describe estimated installations and blocked requests, not confirmed compromises.
The vulnerable endpoint can return email integration API keys, SMTP secrets, and OAuth tokens. Valid credentials can let an attacker send through legitimate mail services already authorized for your domain.
- Update Gravity SMTP to the latest available release before installing replacement credentials.
- Revoke exposed credentials at the provider and configure fresh API keys, SMTP passwords, or OAuth tokens.
- Check mail provider logs, DMARC aggregate reports, bounces, and blocklist (blacklist) signals.
What happened
CVE-2026-4020 is an unauthenticated sensitive information exposure issue in Gravity SMTP, a WordPress plugin used to connect sites to external email delivery providers. Its mock-data REST endpoint had a permission callback that always returned true, so it performed no authentication or capability check. Adding the settings page query parameter caused the endpoint to return about 365 KB of JSON containing the full System Report.
The exposed report can contain mail integration API keys, secrets, and OAuth tokens. It can also disclose the WordPress version and configuration, active plugins and versions, the active theme, PHP and web server details, document paths, database metadata, and table names. Valid credentials with sending permissions give an attacker a usable mail path, while the configuration details support follow-on attacks.
Vulnerable request patternHTTP
GET /wp-json/gravitysmtp/v1/tests/mock-data?page=gravitysmtp-settings Host: affected-wordpress-site.example
|
|
|---|---|
CVE | CVE-2026-4020 |
Affected | Gravity SMTP 2.1.4 and older |
First fixed release | |
Response | Example response: approximately 365 KB of System Report JSON |
Install base | About 100,000 active installs, estimated in June 2026 |
Attempts | More than 17 million blocked requests reported on June 17, 2026 |
Peak | More than four million blocked on June 7, 2026 |
Verified version details and June 2026 reporting figures.
Do not wait for spam complaints or proof of credential misuse before rotating secrets. The endpoint can leak secrets without changing site content, creating accounts, or leaving an obvious WordPress admin trail. Access logs and provider logs are the main evidence sources.
How stolen credentials can pass DMARC
A normal plugin information leak can disclose versions, paths, database metadata, and other reconnaissance value. This flaw also exposes an email sending risk because API keys and OAuth tokens can give an attacker the ability to send mail through services your organization already authorized.
Typical site data exposure
- Reveals plugin versions, server details, paths, and configuration clues.
- Helps attackers choose later attacks against the same WordPress site.
- Often shows up only in web access logs and error telemetry.
- Usually starts with the affected site and its hosting stack.
Mail credential exposure
- Lets attackers send through trusted integrations tied to your domain.
- Can damage IP and domain reputation if abuse leaves through real providers.
- Can increase mail volume through an existing source while SPF, DKIM, and DMARC still pass.
- Can trigger provider abuse limits, bounces, suspensions, and blacklist listings.
DMARC operators need to look beyond the WordPress patch. A stolen key can produce mail that passes DMARC when SPF or DKIM passes and its authenticated domain matches the visible From domain under the DMARC policy's domain-matching rules. A p=reject policy does not stop abuse through that authorized sending path. Authentication does not prove the business authorized the message or campaign.
Gravity SMTP credential exposure flowchart showing the REST endpoint, leaked mail credentials, unauthorized sending, and DMARC review.
Who needs to act
The affected group is specific: WordPress site owners and operators using Gravity SMTP 2.1.4 or older, especially sites with third-party mail delivery integrations configured. If the plugin is installed but unused, still update it. If it stored credentials while a vulnerable version was publicly reachable, rotate them even when available logs show no suspicious requests.
- Check the installed Gravity SMTP version in WordPress and install the latest available release.
- Search all managed WordPress sites, not only sites reporting mail failures.
- Review provider logs for spikes, new campaigns, new sender identities, and new API calls.
- Preserve web and provider logs with timestamps and time zones before retention periods expire.
- Watch complaint rates, bounce patterns, domain reputation, and blocklist results.
Do not assume the absence of visible spam in WordPress means the credentials were not used. If attackers send directly through an external mail API, the WordPress site can look normal while the mail provider shows the abuse.
Prioritize externally facing production sites first, followed by staging sites with real credentials and inactive sites that still have valid tokens. Old staging sites are easy to miss because they often receive fewer plugin updates while still carrying live mail keys.
How to investigate exposure
Start with web access logs. Matching requests are indicators of attempted exploitation, not automatic proof that credentials were retrieved. Look for requests to the mock-data endpoint, especially requests that include the page parameter for the Gravity SMTP settings view. The request is a read-only GET, so the absence of POST actions, admin logins, or changed content does not clear the site.
Access log searchesBASH
grep -nF -e '/gravitysmtp/v1/tests/mock-data' -e 'page=gravitysmtp-settings' access.log access.log.1 zgrep -nF -e '/gravitysmtp/v1/tests/mock-data' -e 'page=gravitysmtp-settings' access.log.*.gz
Adapt the filenames to your host's log rotation scheme. The WordPress REST API handbook documents query-string routing with rest_route. Include that form and decoded URL-encoded variants in your review; the text searches above are starting points.
If your logs are split across a CDN, load balancer, web server, and application stack, search each layer. CDN logs can show requests blocked upstream. Origin logs can show requests that reached WordPress. Provider logs can show whether stolen credentials were used after the endpoint was hit. Compare HTTP status codes, response sizes, and cache status. A 200 response alone does not prove that secrets were returned.
- Record the Gravity SMTP version before updating if your change process requires evidence.
- Search for the REST route and the settings page query parameter in the same request, including query-string routing.
- Search the full period when the vulnerable version was online, with special attention to June 7 through June 11, 2026.
- Compare source IPs, user agents, and request counts across all affected sites.
- Match suspicious web requests against mail API sends, SMTP logins, and OAuth activity. Normalize timestamps and time zones before correlating records.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A domain health check does not prove whether the Gravity SMTP endpoint was exploited, but it gives a fast view of DNS authentication state before and after remediation. That helps separate a credential exposure problem from an existing SPF, DKIM, or DMARC configuration problem.
How to contain exposure before patching
If you cannot update immediately, deactivate Gravity SMTP or temporarily block the affected REST route at the web server or an existing web application firewall (WAF). Cover both the /wp-json/ path and rest_route query-string routing, and prevent direct access to an unprotected origin.
- Apply the restriction to the origin and any public staging copies, then verify that unauthenticated requests no longer return configuration data.
- Keep blocking limited to the affected route. Disabling the entire WordPress REST API can interrupt site functions.
- If unauthorized sending is underway, revoke affected keys or tokens immediately. Install replacements only after the exposure path is closed.
- Test transactional email after temporary deactivation or containment, including password resets and form confirmations.
Containment reduces further exposure; it does not invalidate secrets already retrieved. Complete the plugin update and provider-side credential rotation even when the route is blocked.
How to rotate and validate mail credentials
Close the exposure path first, then install replacement credentials. If you configure new credentials while the vulnerable endpoint remains reachable, they can be exposed again. After updating or containing Gravity SMTP, revoke and replace every credential configured inside the plugin, including API keys, SMTP passwords, OAuth client secrets, and active OAuth tokens where the provider supports revocation. Include backup integrations and credentials copied to other sites.
Rotation order
- Install the latest available Gravity SMTP release across production, staging, and copied sites, and verify that the endpoint no longer discloses settings.
- Disable old API keys, SMTP passwords, and OAuth tokens in the mail provider account.
- Configure fresh credentials in Gravity SMTP and test normal site mail.
- Look for unauthorized sending, new sender identities, unusual recipients, and suppressed mail.
- Record the vulnerable version, exposure window, credentials replaced, and mail logs checked.
After rotation, send a controlled message through the affected WordPress path and inspect the result with Suped's email tester. Confirm the expected SPF and DKIM results and a DMARC pass for the intended From domain. Verify that provider logs show the replacement credential or reauthorized integration and that old credentials can no longer authenticate.
Incident note templateTEXT
Site: Gravity SMTP version before patch: Patched version: Exposure window: Containment verified: Endpoint hits found: First suspicious request: Last suspicious request: Credentials rotated: Revocation timestamps: Old credential revocation verified: Provider logs reviewed: DMARC sources checked: Blocklist checks completed:
For OAuth-based integrations, revocation matters as much as replacing local settings. A token can remain valid outside WordPress until the provider revokes it or it expires. Revoke refresh tokens or the connected app's authorization where supported, then reconnect. Changing a client secret alone does not guarantee that existing access tokens stop working. If your provider exposes token grants, connected apps, API activity, or security event logs, review those records around the same time window as the web access logs.
What to watch in DMARC and deliverability
The mail side of the response is about finding whether a trusted sending path was abused. DMARC aggregate reports are useful because they show sources sending as your domain, SPF and DKIM results, domain matching, and volume changes. They do not show message bodies or prove who used a credential, so pair them with provider logs and abuse notifications. Reports are delayed and cover only participating receivers that send to your configured rua address. Enabling reporting after the incident does not recreate earlier traffic.
Suped is our DMARC and email authentication platform. Its DMARC monitoring turns aggregate reports into source-level views and alerts for new or failing senders. During this response, compare normal WordPress mail volume with sudden traffic changes, including traffic through familiar sources, then use provider logs to determine whether the sending was authorized.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Also watch for blocklist impact. Unauthorized sending through a legitimate provider can still produce complaints, spam-trap hits, hard bounces, and throttling. Suped's blocklist monitoring tracks IP and domain listing signals while credentials are rotated and sending returns to its expected pattern.
Post-incident monitoring signals
Use these signals to prioritize investigation after credential rotation. Normal authentication results do not prove that a credential was unused.
Normal
Continue review
Expected sending volume and authentication results, with no new blocklist listings.
Warning
Review logs
New source, sudden volume jump, new bounces, or an authentication failure pattern.
Critical
Escalate
Confirmed unauthorized sending, continued abuse after rotation, or a new blocklist listing.
Unknown
Verify revocation
No logs, missing DMARC data, or provider history unavailable for the exposure window.
How to limit damage from exposed credentials
Credential design determines how much damage a future disclosure can cause. Give each WordPress site its own sending credential where the provider supports it, and avoid sharing the same SMTP password or API key across production sites, staging copies, and unrelated applications. A site-specific credential can be revoked without interrupting every sender, and its activity is easier to trace.
- Issue a distinct credential for each site or application so one leak has a bounded scope.
- Grant only the sending permissions and sender identities the site needs, following least privilege.
- Use provider-side IP restrictions, recipient limits, or domain restrictions when available.
- Set volume thresholds and alerts near the site's normal sending level.
- Delete inactive plugins, unused connectors, and live secrets from staging or copied sites.
These controls do not replace patching. They reduce the number of systems affected by one leaked secret, lower the amount of mail an attacker can send, and make provider activity easier to attribute during an investigation.
Frequently asked questions
Gravity SMTP 2.1.4 and older are affected. Version 2.1.5 is the first release that fixes CVE-2026-4020; install the latest available release.
It can expose a System Report with configured email integration credentials, WordPress configuration details, plugin and theme inventories, server information, database metadata, API keys, secrets, and OAuth tokens.
Yes, if a publicly reachable vulnerable version stored third-party mail credentials. The request can expose secrets without changing WordPress content or creating obvious admin activity. Rotate shared credentials in every application that uses them.
Aggregate reports can show source and volume changes, but abuse through an existing authorized source can still pass DMARC. They cannot identify who used a credential or provide recipient-level detail. Use mail provider logs to confirm credential use and affected recipients.
Inventory all client WordPress sites, find Gravity SMTP installs, update every affected site, rotate stored credentials, and monitor each client domain for unusual sending volume or listing changes.
