Attackers are actively exploiting a patched Gravity SMTP vulnerability that can expose WordPress site configuration details and mail-service credentials, turning what looks like a medium-severity plugin bug into an urgent cleanup task for site owners.
The flaw, tracked as CVE-2026-4020, affects Gravity SMTP versions up to and including 2.1.4. Gravity Forms’ documentation lists version 2.1.5 as adding security enhancements, and Wordfence says sites should update to at least that version. The current Gravity SMTP line has since moved beyond that patch, so the practical target is simple: update the plugin now, then treat any exposed email integration secrets as potentially compromised.
Wordfence disclosed the issue in March, but its latest advisory says exploitation has now reached large scale. The company reported that its firewall had blocked more than 17 million exploit attempts, with a sharp spike in early June and more than 4 million blocked requests on June 7 alone. BleepingComputer also reported the active exploitation on June 19, bringing wider attention to a bug that may still be sitting quietly on unpatched WordPress sites.
What the Gravity SMTP Bug Exposes
Gravity SMTP is used to route WordPress email through outside services so form submissions, password resets, store notifications, membership emails, and other site messages are more likely to be delivered. That job often requires connecting the plugin to mail providers such as Amazon SES, Google, Mailjet, Resend, Zoho, or other SMTP and API-based services.
The vulnerability sits in a REST API endpoint: /wp-json/gravitysmtp/v1/tests/mock-data. According to Wordfence’s technical write-up, the endpoint’s permission check unconditionally returned true in affected versions. When an attacker appends ?page=gravitysmtp-settings, the plugin can return a large JSON system report without requiring a login.
That report may include PHP and web server versions, the WordPress version, active plugins and their versions, active theme details, database information, table names, document root paths, and WordPress configuration details. More importantly, it can include API keys, secrets, and OAuth tokens configured for Gravity SMTP’s mail integrations.
This is not a remote-code-execution bug by itself. The risk is that it gives attackers both credentials and reconnaissance. A stolen mail-service token can be abused to send email through a site owner’s trusted provider, while the exposed plugin and server inventory can help attackers decide which follow-up vulnerabilities to try next.
Why a Medium-Severity Score Can Still Matter
CVE-2026-4020 has been described with a medium Wordfence score in some advisories, while the NVD page shows a CNA CVSS 3.1 base score of 7.5, high, with network access, low attack complexity, no privileges, and no user interaction. The scoring discrepancy is less important than the operating reality: attackers do not need an account, a phishing click, or an admin mistake after installation. They only need the vulnerable endpoint to be reachable.
CrowdSec’s tracking gives that reality more context. Its vulnerability report says it first observed in-the-wild exploitation on May 27 and saw 412 distinct attacking IPs by June 1. CrowdSec classifies the activity as broad background exploitation, meaning the bug has moved into routine internet scanning rather than remaining a niche researcher or targeted-attack issue.
For small businesses and ecommerce sites, the exposed data is especially useful. Mail credentials can be valuable for spam, phishing, invoice fraud, password-reset abuse, and reputation damage. A site that sends legitimate order confirmations or customer messages may have enough sending trust to make malicious mail harder for recipients to spot.
What Site Owners Should Do Now
The first step is to update Gravity SMTP to the latest available version. Any site still running 2.1.4 or older should be treated as exposed if the plugin has been internet-accessible. Updating closes the vulnerable behavior, but it does not undo access that may already have happened.
Next, review web server access logs for requests to /wp-json/gravitysmtp/v1/tests/mock-data, especially requests that include ?page=gravitysmtp-settings. Because the exploit is a simple GET request that reads data rather than changing files, site owners should not expect an obvious defacement, new admin account, or broken page as proof of compromise.
If the site used Gravity SMTP with Amazon SES, Google, Mailjet, Resend, Zoho, or another third-party email connector while it was vulnerable, rotate the related API keys, OAuth tokens, SMTP passwords, and client secrets. Then check the mail provider’s logs for unusual sending volume, new authorized apps, unfamiliar IP addresses, bounces, complaints, or campaigns that were not created by the site owner.
Administrators should also review the rest of the exposed stack. If the system report revealed outdated plugins, theme versions, PHP details, or database information, assume attackers may use that inventory to look for additional weaknesses. Patch other plugins and themes, remove unused extensions, check administrator accounts, and make sure backups are current before dismissing the event as only an information leak.
Why This Is a WordPress Pattern, Not Just One Plugin
WordPress plugin bugs often become dangerous because of where plugins sit in a site’s trust chain. A contact-form plugin may touch customer data. An ecommerce plugin may handle orders. A mail plugin may hold credentials for external systems. Even when a bug does not directly create an admin account or run code, it can hand attackers the information they need to do something more damaging later.
Gravity SMTP’s vulnerable endpoint is a clean example: a development or diagnostic-style data path was reachable without a meaningful permission check, and the returned system report contained exactly the kind of operational detail attackers collect during reconnaissance. Once exploitation becomes automated, the window between “patched” and “actually safe” depends on whether site owners update, rotate secrets, and check logs rather than only relying on the plugin update notice.
For agencies and hosting providers, this should become a checklist item across managed WordPress fleets. Search for Gravity SMTP installations, confirm plugin versions, look for the mock-data endpoint in logs, rotate affected mail credentials, and document which sites had third-party email connectors configured. The same workflow will be useful the next time a plugin turns an internal report, debug endpoint, or setup helper into an unauthenticated data feed.
