On June 7, attackers sent 4 million requests through a single unauthenticated REST API endpoint in the Gravity SMTP WordPress plugin. By that point, the vulnerability had been public for nearly three months. The plugin's developers had shipped a fix on March 17, but most sites were still running the vulnerable version.
This incident highlights the critical need for proactive vulnerability management and timely patching of WordPress plugins.
What Happened
CVE-2026-4020, an unauthenticated information disclosure vulnerability in Gravity SMTP, allowed attackers to query a REST API endpoint without authentication. The flaw affected all versions through 2.1.4 and exposed sensitive configuration data to anyone who knew where to look.
The vulnerability had a medium severity rating, often deprioritized in development cycles. However, between the March 17 patch release and mid-June, Wordfence blocked over 17 million exploit attempts against their protected customers. Sites without that protection were left exposed.
Timeline
March 17: Gravity SMTP version 2.1.5 released with a fix for the REST API authentication bypass.
March 17 - June 6: Steady exploitation activity as attackers scan for unpatched installations.
June 7: Exploitation spikes to 4 million blocked requests in a single day.
Present: Thousands of sites remain vulnerable because administrators haven't applied the update.
The timeline shows a familiar pattern: patch available, exploitation begins immediately, most sites remain vulnerable for months.
Which Controls Failed
Missing authentication on REST API endpoints. The plugin exposed data through an API endpoint that performed no authentication check. Any request from any source could retrieve configuration information. This is OWASP API Security Top 10 API1:2023 (Broken Object Level Authorization) — you must verify that the requesting user has permission to access the specific data they're requesting.
No automated patch management. WordPress can auto-update plugins, but many teams disable this feature due to concerns about breaking changes. The result: sites running vulnerable code for months after a fix is available.
Insufficient monitoring of exploitation attempts. Sites without a web application firewall had no visibility into the 17 million attack attempts. You can't respond to threats you don't see.
No compensating controls for third-party code. WordPress plugins run with the same privileges as core WordPress code. There's no isolation, no additional authentication layer, no runtime protection. If the plugin is vulnerable, your site is vulnerable.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 states that security vulnerabilities are identified using industry-recognized sources and that patches are installed within one month of release for high-risk vulnerabilities. While this CVE was rated medium severity, active exploitation elevates the risk. If you process payments on WordPress, you need a process that catches actively exploited vulnerabilities regardless of their CVSS score.
OWASP ASVS v4.0.3 Section 4.1.1 requires that all API endpoints enforce access control at the business logic layer. The application must verify authorization before processing any request. A REST API endpoint that returns data without checking who's asking fails this requirement.
ISO/IEC 27001:2022 Control 8.8 (Management of technical vulnerabilities) requires you to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. "Appropriate measures" when exploitation is active means patching immediately, not waiting for your quarterly update cycle.
NIST CSF v2.0 PR.IP-12 requires you to manage vulnerabilities and apply updates in a timely manner. The framework doesn't specify what "timely" means, but when Wordfence is blocking 4 million attempts in a day, you're past timely.
Lessons and Action Items
Enable selective auto-updates for security patches. WordPress supports automatic updates for plugins. Yes, there's a risk of breaking changes. But you can test updates in staging first, or enable auto-updates only for security releases. The alternative — manual updates that never happen — is worse.
Configure this in your wp-config.php:
add_filter('auto_update_plugin', function($update, $item) {
return (isset($item->plugin) &&
in_array($item->plugin, ['gravity-smtp/gravity-smtp.php']));
}, 10, 2);
Deploy a web application firewall. The 17 million blocked attempts represent only the sites behind Wordfence. If you're running WordPress in production without a WAF, you have no visibility into exploitation attempts and no way to block them while you're patching. Cloudflare, Wordfence, Sucuri, or ModSecurity all provide this capability.
Audit your REST API authentication. Every WordPress site exposes REST API endpoints. Run wp-json/wp/v2/users against your site right now. If it returns user data without authentication, you have the same class of vulnerability that hit Gravity SMTP. Review every custom endpoint and every plugin that registers routes.
Create a security-critical patch process. Your normal update cycle might be monthly or quarterly. You need a separate process for actively exploited vulnerabilities: notification within 24 hours, emergency change approval, patching within 72 hours. Document who can authorize an emergency patch and how you'll test it.
Monitor plugin vulnerability feeds. WPScan maintains a vulnerability database at wpvulndb.com. Subscribe to notifications for the plugins you use. When a CVE drops, you should know before your monitoring dashboard lights up with blocked exploit attempts.
Implement defense in depth for third-party code. WordPress plugins run with full application privileges. You can't fix that architecture, but you can limit the blast radius: run WordPress in containers with restricted permissions, use read-only filesystems where possible, segment your database access so a compromised plugin can't access payment data.
The Gravity SMTP incident wasn't sophisticated. It was attackers running automated scans for a known vulnerability against sites that hadn't patched in three months. That's not a zero-day. That's a patch management failure.
If you're still running Gravity SMTP 2.1.4 or older, update to 2.1.5 now. If you don't know which version you're running, that's the bigger problem.
