In May and June 2026, attackers exploited a critical vulnerability in the Gravity SMTP WordPress plugin to harvest live API keys, OAuth tokens, and service credentials from approximately 100,000 websites with a single unauthenticated HTTP GET request. Wordfence blocked over 17 million exploitation attempts. CrowdSec classified the activity as background noise within days, meaning the exploit had been incorporated into automated scanning routines that sweep the internet continuously. This is CVE-2026-4020: a permission check that always returns true, an exposed REST API endpoint, and 365 kilobytes of live credentials returned to anyone who asked.
What Happened
The Gravity SMTP plugin, developed by RocketGenius, is a widely used WordPress email integration tool installed on approximately 100,000 sites. It allows site administrators to configure external email service providers — Amazon SES, Google, Mailjet, Resend, Zoho — and stores the API keys, OAuth tokens, and service credentials required to send email through those providers.
The vulnerability, tracked as CVE-2026-4020, was patched in Gravity SMTP version 2.1.5 on 17 March 2026. The CVE was published on 31 March 2026. Exploitation at industrial scale began in late May and peaked on 7 June 2026, when Wordfence blocked more than four million exploitation attempts in a single day.
The timeline:
- March 17, 2026: Gravity SMTP version 2.1.5 ships with the fix
- March 30-31, 2026: CVE-2026-4020 published publicly
- May 5, 2026: Wordfence deploys firewall protection for premium subscribers after internal monitoring identifies escalating activity
- May 22, 2026: CrowdSec deploys detection for CVE-2026-4020
- May 27, 2026: First confirmed real-world exploitation observed by CrowdSec
- June 1, 2026: CrowdSec classifies activity as background noise — 412 distinct attacking IPs identified
- June 4, 2026: Wordfence free-tier users receive firewall protection
- June 7, 2026: Peak exploitation — 4 million blocked attempts in a single day
- June 2026: Wordfence total blocked attempts exceed 17 million
How It Happened
The vulnerability is technically simple and operationally devastating. In WordPress, every custom REST API endpoint must include a permission_callback function — a gate that checks whether the requesting user is authorised to access that endpoint. In affected versions of Gravity SMTP, the permission_callback for the internal test endpoint at /wp-json/gravitysmtp/v1/tests/mock-data unconditionally returns true. No authentication check. No capability check. Any unauthenticated visitor can call the endpoint.
When the query parameter ?page=gravitysmtp-settings is appended, the plugin assembles a comprehensive JSON System Report and returns it in the response. The report is approximately 365 kilobytes and contains:
- Live API keys and OAuth tokens for all configured email integrations
- Credentials for Amazon SES, Google, Mailjet, Resend, and Zoho
- Full WordPress configuration details including all installed plugins and themes
- PHP version, loaded extensions, and web server details
- Database connection metadata
- Document root path and server environment information
The complete attack is a single HTTP GET request:
GET /wp-json/gravitysmtp/v1/tests/mock-data?page=gravitysmtp-settings HTTP/1.1
No account. No password. No prior access to the site. The entire credential inventory of the site’s email infrastructure is returned in the response.
Detection is particularly difficult because this is a read-only operation. The vulnerability does not create new administrator accounts, drop web shells, or modify any files. Traditional compromise indicators are absent. The credentials are stolen silently, and the theft may not be discovered until the stolen API keys are abused.
Impact
CrowdSec identified 412 distinct attacking IP addresses between 27 May and 1 June alone, predominantly from cloud and hosting infrastructure in France, the Netherlands, and the United States — a pattern consistent with automated scanning routines rather than targeted attack. The speed of industrialisation reflects the vulnerability’s properties: no authentication required, single HTTP request, high-value credential payload, trivially automatable at internet scale.
Any site running a vulnerable version of Gravity SMTP with configured email integrations should assume that their API keys, OAuth tokens, and service credentials have been exposed. The three-month gap between patch availability and peak exploitation is a familiar pattern: patches ship, exploitation begins at scale weeks later when automation picks up the CVE.
The stolen credentials represent a directly usable attack capability: an attacker holding a victim’s Amazon SES API key can send email through the victim’s account, impersonating the victim to recipients. This enables phishing campaigns that originate from legitimate infrastructure, bypassing most email security controls.
What This Means for NHI Governance
CVE-2026-4020 is not fundamentally a vulnerability story. It is a credential governance story.
The credentials exposed by this vulnerability are non-human identities. API keys for Amazon SES, OAuth tokens for Google Workspace email, service credentials for Mailjet — each of these is a non-human identity with standing access to a cloud service. They authenticate automatically, without human involvement, every time the WordPress site sends an email. They have no expiry. They are rarely rotated. And in most WordPress deployments, they are completely invisible to any security programme.
The NHI governance failures this vulnerability exposes:
- No credential rotation programme: Sites that had deployed Gravity SMTP had no systematic process for rotating their email service credentials. Long-lived API keys are the default, not the exception.
- No monitoring for credential abuse: Stolen Amazon SES keys being used to send bulk email from an attacker’s server would not trigger any alert on the victim’s WordPress site. The credentials are used externally with no visibility back to the site owner.
- Insufficient access control on credential-storing endpoints: A REST API endpoint that returns live production credentials should require at minimum administrator-level authentication. The permission_callback architecture in WordPress makes this straightforward, the flaw was a deliberate design choice that should have been caught in code review.
- Patch deployment gap: The three-month window between patch availability and peak exploitation reflects a systemic failure to treat plugin updates as security-critical events. For 100,000 sites, a free security update was available for months while active credential harvesting occurred.
Recommendations
- Update Gravity SMTP to version 2.1.5 or later immediately. If you are running any version through 2.1.4, update now.
- Rotate all configured email service credentials. If you were running a vulnerable version, assume your API keys and OAuth tokens are compromised. Rotate credentials for Amazon SES, Google, Mailjet, Resend, Zoho, and any other configured email provider.
- Check server access logs for exploit attempts. Review logs for GET requests to
/wp-json/gravitysmtp/v1/tests/mock-data. The absence of exploitation in your logs does not confirm safety, many requests will not have generated an access log entry depending on server configuration. - Implement a WordPress plugin update policy. Treat plugin updates as security-critical operations, not optional maintenance. Credential-storing plugins especially should be updated within 24 hours of a security patch.
- Monitor email service credential usage. Enable usage monitoring and anomaly alerts on Amazon SES, Google SMTP, and other configured email providers. Unexpected sending volumes, unusual sender domains, or access from unfamiliar IP addresses should trigger immediate investigation.
- Block the vulnerable endpoint at the WAF level. For sites that cannot patch immediately, block unauthenticated access to
/wp-json/gravitysmtp/v1/tests/mock-datavia web application firewall rules.
How NHI Mgmt Group Can Help
Securing Non-Human Identities (NHIs) including AI Agents, is becoming increasingly crucial as attackers discover and target service accounts, API keys, tokens, secrets, and OAuth credentials during breaches. These NHIs often hold extensive permissions that can be exploited, making their security a priority for any organisation focused on protecting their digital assets.
Take our NHI Foundation Level Training Course, the most comprehensive in the industry, that will empower you and your organisation with the knowledge needed to manage and secure these non-human identities effectively.
Final Thoughts
CVE-2026-4020 illustrates the most persistent failure mode in NHI security: credentials that exist in production systems, hold standing access to cloud services, and are completely invisible to the security programmes responsible for protecting those organisations. The vulnerability was fixed in March. Exploitation peaked in June.
The gap is not a technical problem. It is a governance problem, the absence of any systematic process for ensuring that credential-storing systems are kept current, that the credentials they store are rotated regularly, and that their use is monitored for anomalous behaviour. Seventeen million blocked attempts is the cost of that gap at scale.
