Hackers Exploit Gravity SMTP WordPress Plugin Flaw To Steal Site Configuration Data

Hackers are actively exploiting a Gravity SMTP vulnerability that can expose sensitive WordPress site data without requiring a login. The flaw affects Gravity SMTP versions 2.1.4 and older and is fixed in version 2.1.5.

The vulnerability is tracked as CVE-2026-4020. According to Wordfence, attackers have been using the bug at scale to pull detailed system reports from vulnerable WordPress sites.

The plugin is used to route WordPress emails through SMTP and API-based email providers. The official Gravity SMTP product page says it supports providers such as SendGrid, Mailgun, Postmark, Brevo, Google, Microsoft, Amazon SES, Resend, Zoho Mail, and other services.

What CVE-2026-4020 Exposes

CVE-2026-4020 is an unauthenticated sensitive information exposure flaw in Gravity SMTP. The issue comes from a REST API endpoint that can return plugin and system data to anyone who sends the right request.

The Wordfence vulnerability record says the exposed endpoint is located at /wp-json/gravitysmtp/v1/tests/mock-data and that its permission callback unconditionally returns true. When attackers add the ?page=gravitysmtp-settings query parameter, the endpoint can return a full system report.

The NVD entry says the data can include PHP version, loaded extensions, web server details, document root path, database information, WordPress version, active plugins, active theme, table names, and configured API keys or tokens.

Item	Details
Vulnerability	CVE-2026-4020
Affected plugin	Gravity SMTP for WordPress
Affected versions	2.1.4 and older
Fixed version	2.1.5 or later
Attack requirement	No authentication required
Main risk	Exposure of site configuration data and email service credentials

Why A Medium-Rated Bug Still Matters

The vulnerability carries a medium severity rating in several WordPress security databases, but site owners should not treat it as low priority. A remote attacker can exploit the issue without a username or password if the vulnerable endpoint is reachable.

WPScan describes the issue as unauthenticated sensitive information exposure through the REST API and lists Gravity SMTP versions before 2.1.5 as affected.

The risk depends on what the site has configured inside Gravity SMTP. If live API keys, OAuth tokens, SMTP credentials, or third-party email secrets appear in the exposed report, attackers may be able to abuse the site’s connected email services.

• Attackers can query the vulnerable endpoint without logging in.
• The exposed report may reveal email integration secrets.
• Site software versions can help attackers plan follow-up attacks.
• Database and server details can reveal useful reconnaissance data.
• Stolen email credentials can support spam, phishing, or impersonation.

How Attackers Are Using The Gravity SMTP Bug

The attack is simple enough to automate. Attackers scan for WordPress sites running Gravity SMTP, then request the exposed REST API endpoint and look for the system report output.

BleepingComputer reported that Wordfence had blocked more than 17 million exploit attempts against protected customers. The heaviest activity cited by researchers included a spike of about 4 million blocked requests on June 7.

The most important log indicator is a request to /wp-json/gravitysmtp/v1/tests/mock-data, especially when the request includes the ?page=gravitysmtp-settings parameter. Administrators should search web server logs, CDN logs, WAF logs, and WordPress security logs for that path.

Log Indicator	Why It Matters
/wp-json/gravitysmtp/v1/tests/mock-data	Core endpoint abused in exploitation attempts
?page=gravitysmtp-settings	Parameter used to trigger more complete report data
Large numbers of repeated GET requests	May indicate automated scanning or exploitation
Requests from unfamiliar hosting or proxy networks	May indicate mass exploitation infrastructure

Patch Status And Fixed Versions

The fix is available in Gravity SMTP 2.1.5 and newer. The official Gravity SMTP changelog lists version 2.1.5 with security enhancements, followed by later maintenance releases.

Administrators should update to the latest available Gravity SMTP version, not only 2.1.5, because later releases may include additional fixes and stability improvements. Sites that use Gravity SMTP for transactional email should test sending after the update.

The Wordfence advisory says active exploitation drove the company to deploy firewall protection even though the original severity assessment was below its normal threshold for a rule.

What Site Owners Should Do Now

WordPress administrators should first check whether Gravity SMTP is installed and whether the version is 2.1.4 or older. If it is, they should update immediately.

After updating, admins should rotate any exposed email service credentials. That includes API keys, SMTP passwords, OAuth credentials, and secrets for providers configured inside the plugin.

The vulnerability database entry recommends updating to 2.1.5 or a newer patched version. Site owners should also review whether attackers queried the endpoint before the patch was applied.

1. Update Gravity SMTP to the latest available version.
2. Search logs for /wp-json/gravitysmtp/v1/tests/mock-data.
3. Look for requests that include ?page=gravitysmtp-settings.
4. Rotate all email service API keys and SMTP passwords configured in the plugin.
5. Review email provider logs for unusual sending activity.
6. Check WordPress admin accounts for suspicious changes.
7. Confirm that no unknown plugins, themes, or users were added.

Email Credentials Are The Biggest Concern

Gravity SMTP connects WordPress sites to external email services. That means a leaked credential may give attackers more than information about the site. It may let them send email through a trusted domain or service account.

Abused email accounts can create reputation damage, domain blocklisting, phishing risk, and higher email delivery failure rates. Businesses using Gravity SMTP for order confirmations, password resets, form notifications, or customer communication should treat exposed credentials as sensitive.

The official Gravity SMTP page says the plugin works across site emails, including user registrations, password resets, and notifications from other plugins. That makes credential hygiene especially important for ecommerce and membership sites.

How To Reduce Future Plugin Exposure

This incident shows why WordPress administrators should review plugin endpoints, update cadence, and credential storage practices. A plugin does not need remote code execution to create serious risk if it exposes secrets or internal configuration data.

The CVE-2026-4020 record identifies the issue as sensitive information exposure through a REST API endpoint. That kind of flaw can help attackers build a map of a site before launching other attacks.

Administrators should also reduce the number of long-lived secrets stored inside WordPress. Where supported, they should use least-privilege API keys, rotate credentials on a schedule, and monitor email provider dashboards for unusual sending behavior.

Security Control	Benefit
Automatic plugin updates for trusted plugins	Reduces exposure time after patches ship
Least-privilege email API keys	Limits what stolen credentials can do
WAF or security plugin rules	Blocks known exploit patterns before patching
Centralized web server logs	Helps confirm whether exploitation happened
Email provider monitoring	Detects unusual sending after credential theft

Related WordPress Plugin Risk

The Gravity SMTP exploitation wave comes during another busy period for WordPress plugin security. BleepingComputer also noted a separate Avada Builder vulnerability that could allow arbitrary file deletion under certain conditions.

The two issues are different, but they point to the same operational problem. WordPress sites often depend on many plugins, and attackers move quickly when a flaw can be scanned or exploited at scale.

The WPScan listing shows the Gravity SMTP issue was published on March 30 and later updated in June, while the official plugin changelog shows the security update was already available before the mass exploitation reports. Sites that delayed updates remained exposed longer than necessary.

FAQ