The Gravity SMTP vulnerability (CVE-2026-4020) has produced a remarkable set of numbers. More than 17 million blocked exploit attempts. Four million blocked requests in a single day. An unauthenticated endpoint returning the full system configuration of any affected WordPress site in one HTTP GET request. But the specific flaw matters less than the question it raises. Why would an email plugin hold your most sensitive API credentials without meaningful protection around them?
Table of Contents
What made the Gravity SMTP vulnerability so damaging
Gravity SMTP stores API keys and OAuth tokens inside the WordPress database. These credentials cover email providers including Amazon SES, Google, Mailjet, Resend, and Zoho. That design is standard across the plugin ecosystem. It is also, when you think about it, asking for trouble.
The flaw sits in a REST API endpoint at /wp-json/gravitysmtp/v1/tests/mock-data. The plugin registered this endpoint with a permission callback that unconditionally returns true. So anyone could query it without a valid session. Appending ?page=gravitysmtp-settings returned the plugin’s full system report. This covered PHP version, web server details, WordPress version, active plugins, database metadata, table names, and any credentials stored in the connector settings.
That permission callback is almost a secondary issue. The primary issue is that the credentials existed in accessible form inside a system that attackers probe constantly. One logic error in one callback function, and all of that infrastructure access went out in a single 365KB JSON dump.
Wordfence put it plainly: “The exposure of live third-party API credentials means an attacker could abuse the site’s connected email services, while the detailed system report significantly lowers the effort required to plan further attacks.” That second clause matters. Even without the API keys, the system report is a reconnaissance package. It tells an attacker exactly where to probe next.
What happens when email credentials are stolen
API keys for Amazon SES or Google’s sending infrastructure are not like a website password. They authenticate your sending identity at the protocol level. So mail sent through them passes SPF, DKIM, and DMARC checks as if it came legitimately from your domain. That means phishing messages to your customers or suppliers, carrying your real domain name and your real sending reputation. Recipients have no technical reason to distrust them.
The consequences compound quickly. First, email providers can suspend accounts that generate spam complaints. Your domain can end up on blocklists. Customers receive convincing-looking fraudulent messages. AWS SES bills by the message, so a week of unreported credential abuse can produce a substantial invoice. None of this requires the attacker to gain any further access to your WordPress site. The credentials alone are enough.
The plugin ecosystem’s consent problem
WordPress plugins routinely ask for permission to store sensitive credentials. Site owners routinely grant it, because there is no obvious alternative. You want outbound email routing, so you install Gravity SMTP. You accept that the plugin needs your Amazon SES key to function. Trusting the plugin author to secure the storage mechanism is simply part of the deal.
In many cases, that trust is warranted. The Gravity SMTP vulnerability is not evidence of negligence on the developer’s part. It is evidence that a permission callback function contained a logic error. That kind of mistake is not rare, and it is not unique to smaller developers. What makes it serious is the combination: a widely installed plugin, credentials with real downstream access, and a flaw that requires no authentication to exploit.
The risk is structural, though. When an email plugin holds your Amazon SES key, the attack surface is wide. A vulnerability anywhere in the plugin’s REST API, settings page, or update mechanism can open a path to credential theft. So the attack surface extends to every line of code that touches the stored credentials.
What a better model looks like
Some teams deal with this by not storing credentials in WordPress at all. They configure an SMTP relay at the server or hosting level. WordPress plugins then see only a local SMTP connection and never hold provider keys. The relay handles authentication to the external provider. That separation does not eliminate all risk, but it removes the most common credential-theft vector from the WordPress layer.
For organisations that cannot restructure their setup right now, the practical response is clear. Patch to version 2.1.5. Rotate every credential stored in the plugin. Check your sending provider’s logs for activity after 27 May 2026, when exploitation began. Then audit which other plugins on your site hold sensitive credentials and whether those plugins are current.
The right question after the Gravity SMTP vulnerability
Attackers targeted the Gravity SMTP vulnerability at mass scale because the maths worked. There were 100,000 sites, each potentially holding API keys with real downstream value. The exploit needed just one unauthenticated request. The patch is version 2.1.5. But the deeper question is worth sitting with. Does your current setup require you to trust plugin authors with credentials that cause serious problems if exposed?
That is not a criticism of Gravity SMTP specifically. It is worth asking for every plugin that stores API keys, webhook secrets, or OAuth tokens in your database. Security testing means reviewing what is stored, how it is protected, and what happens if that protection breaks.
Subscribe to our newsletter for a weekly round up of what's happening in the cyber security world
