My email provider has disabled my API key
The service that sends your order emails cuts your key without warning, or reports usage coming from somewhere else. Very often that is the result of a plugin that exposed your credentials to anyone who knew where to look.
The alert always comes from outside
The pattern rarely changes. You noticed nothing on your store, everything seemed fine, and a third party tells you: your email provider suspends the account key, or flags an unusual sending volume, or your invoice shows thousands of messages you never triggered. Sometimes the first sign is quieter still — order confirmations stop going out, although nobody touched the configuration.
A provider that cuts a key rarely does so at random. It has seen mail leaving from infrastructure that is not yours, or content that looks nothing like your normal traffic. The key still works: it is simply being used by someone else. And if someone else is using it, it was read somewhere.
In the cases I deal with, that somewhere is almost never your own computer. It is the site itself, through a plugin that held the credentials and made them readable to anyone who knew where to look.
What should put you on alert
- Your email provider disables the key without you asking for anything.
- You get an alert about abnormal sending volume, or an invoice unrelated to your activity.
- Order confirmation emails stop going out, although nothing changed in your configuration.
- The provider dashboard shows sends to recipients who are not your customers.
- Your domain name starts being flagged as a source of spam.
- An email sending plugin is installed on the site and has not been updated for months.
What a sending plugin stores, and what a system report really holds
A plugin that handles transactional email has to connect to an outside service, and for that it needs a secret: an API key, an authorisation token, sometimes a username and password. That secret is written to the site database, in a configuration table, in a form the plugin must be able to read back on every send. So it cannot really be protected: whatever the plugin can read, any code able to query the same place can read too.
On top of that sits a feature found in almost all of these plugins: the system report. It is the file you are asked to attach when you open a support ticket. In one place it gathers the WordPress and PHP versions, server details, database details, the inventory of installed plugins, the active theme, and the configuration of the email connectors — meaning the keys and the tokens. It is not a harmless diagnostic file. It is a full description of your installation, secrets included. Treat it like a password, not like a screenshot.
CVE-2026-4020 shows the point exactly. It affects the Gravity SMTP plugin, running on roughly 100,000 sites, in every version up to and including 2.1.4. One of the plugin's REST API endpoints did have a permission check, but that check always returned true: the door was locked, and the lock said yes to everyone. The endpoint then returned about 365 KB of JSON — the complete system report: API keys and OAuth tokens for the connected email services (Amazon SES, Google, Mailjet, Resend, Zoho), database details, WordPress and PHP versions, server information, plugin inventory and active theme. The fix, version 2.1.5, shipped on 17 March 2026; the flaw was published on 31 March 2026.
What followed is the part that concerns you. Mass exploitation began in early May 2026 and peaked on 6 and 7 June 2026, with more than 4 million requests blocked in a single day and more than 17 million attempts in total according to Wordfence. At that scale the question is not whether your site was probed, but whether it was up to date when it was.
The right order of operations after a key leak
-
Close the leak before touching the key
If you issue a new key while the plugin that exposed the old one is still in place and unpatched, the new one leaks by the same route, sometimes within hours. So the first action is updating that plugin, or disabling it temporarily if updating is not immediately possible.
-
Create the new key before revoking the old one
Most sending providers allow several keys to coexist. Create the new one, save it in the site configuration, send a test email, confirm it arrives, and only then revoke the old one. A key revoked but not replaced kills every order confirmation, and you find out through customer complaints.
-
Revoke before you understand everything
Analysis can take days; the key is usable in a second. I revoke first and understand afterwards. The reverse leaves an open door for the whole duration of the investigation, which is never a good trade.
-
Treat the other secrets as compromised
What comes out in a system report is not just the sending key. Tokens for the other email connectors, database credentials and the whole exposed configuration must be treated as known. Regenerate what can be regenerated, change the rest, and write down what you changed.
-
Read the server logs
Once the key is replaced, look through the access logs for REST API calls and the response codes returned. That tells you whether the endpoint was hit on your site, and from what date. If your host keeps only a few days of logs, finding nothing proves nothing.
# Journaux d'acces : appels a l'API REST, groupes par IP et par route
grep -h 'wp-json' access.log* | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -40
# Fichiers PHP modifies dans les 30 derniers jours
find wp-content -type f -name '*.php' -mtime -30 -ls | head -40Related reading
-
My site sends emails I never wrote
The other side of the problem: when the site itself has become the sending machine.
-
Order emails no longer arrive
What customers experience when a key is revoked without being replaced.
-
Checking whether my site is compromised
The checks to run when leaked secrets may have served as an entry point.
-
REST API
What a REST API endpoint is, and why a broken permission check opens everything.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.