A single WordPress plugin that thousands of small businesses use to route their contact-form mail through Amazon SES, Zoho, or Mailjet has been the target of more than 17 million attack attempts in the past few weeks. The plugin is called Gravity SMTP, and the bug, tracked as CVE-2026-4020, exposes the API keys the plugin stores so it can talk to those email providers. When an attacker pulls those keys, they get the ability to send mail as the business, read any responses, and in many cases reach into the connected CRM that uses the same credentials. The fix itself is a one-click plugin update. The harder question is which small businesses have the plugin installed, who installed it, who is supposed to update it, and whether anybody is rotating the leaked keys after the patch lands.
For a small-business owner who has never logged into the WordPress dashboard, the obvious answer is that the website is the marketing team’s problem and the marketing team will sort it out. The less obvious answer is that the plugin in question is not really a marketing tool. It is the piece of glue that lets the website send and receive transactional mail, which means it sits on the same trust path as the office inbox, the CRM, and any automation tied to either one. A plugin that leaks API keys is an IT incident wearing a marketing costume.
What Just Happened With This WordPress Email Plugin?
On June 20 a security research team published evidence that attackers had launched more than 17 million automated requests against websites running the Gravity SMTP plugin in the two weeks following the public disclosure of CVE-2026-4020. The vulnerability lets an unauthenticated attacker read the plugin’s stored settings, which include the API key, secret, and connection details the plugin uses to deliver mail through a third-party provider. A patched version of the plugin (2.1.5 or newer) was released alongside the disclosure, and the WordPress automatic-update path will deliver it to most sites within a week of release if automatic updates are turned on. The number of sites still running the older version four days after disclosure is the part attackers are racing the clock to exploit.
The plugin itself is widely installed because most WordPress sites cannot send reliable mail from their own server without help. Hosting providers block outbound mail to fight spam, deliverability rates from a no-name server are poor, and the default WordPress mail function lands in the junk folder more often than the inbox. An SMTP plugin solves that problem by routing every piece of mail (contact-form submissions, password resets, order confirmations, internal notifications) through a deliverability-focused provider that the business already trusts. The plugin holds the credentials that authorize that routing. When those credentials leak, the attacker can do everything the plugin could do.
The disclosure window matters. Public vulnerability disclosures are usually coordinated with a patched version on day one, but the patch only protects sites that actually install it. Automated scanning tools absorb the disclosure within hours and start hunting for vulnerable installations across the public internet by the end of the day. By the end of the first week, the exploit code is mature, the tooling is broadly available, and the unpatched sites are the ones that get hit at scale. The 17 million attack-attempt number is what that ramp looks like in real time. It is not a measure of how many sites were breached. It is a measure of how aggressively attackers are searching for sites that have not patched yet.
Why Does An Email Plugin Hold The Keys To Your Email And CRM?
The phrase API key is the part of the story that most small-business owners have never had to think about, and it is the part that turns a plugin bug into a real-world business problem. An API key is a long string of characters that proves to a connected service that the request is coming from an authorized account. When the marketing team wires the website to send mail through Amazon SES, they generate an API key in the SES dashboard and paste it into the WordPress plugin’s settings page. From that moment forward, anybody who can read the plugin’s settings can also send mail as the business through that SES account. The provider sees a valid key and assumes the request is legitimate.
The same logic applies to every connected service the plugin touches. A site that uses the SMTP plugin to deliver password-reset emails from the e-commerce store is also storing the credential that gives somebody the ability to send those reset emails to any address they choose. A site that wires the plugin to a CRM webhook so contact-form submissions get attached to the right lead record is also storing the credential that gives somebody the ability to read those leads or impersonate that webhook. The plugin is not just sending mail. It is the master key ring for every connected service the site touches.
The credential-rotation problem compounds this. Most small businesses generate the API keys once during the initial website build, and then nobody touches them again until something breaks. The original web developer is often the only person who remembers which provider the keys belong to and where they live. When that developer rotates off the project, the credentials stay behind. A leak today exposes keys that may have been sitting unrotated for years, with permissions that may have grown over time as additional automations were added. The same dynamic that makes old vendor accounts the hardest credentials to inventory and clean up applies to API keys stored inside WordPress plugins. The keys are invisible to the business owner, fully trusted by the connected service, and forgotten by the person who set them up.
How Does One Plugin Leak Become Email And CRM Compromise?
The exploit path is short and quiet. An attacker scans the public internet for sites running the vulnerable plugin version. When the scanner finds one, it sends an unauthenticated request that reads back the plugin’s stored configuration, including the API key. The attacker now has a working credential for the connected mail provider. From there, the attacker can send mail as the business to any address they choose, with full deliverability through the provider that the business has been building reputation with for years. The attack does not require breaking into the WordPress admin panel, guessing a password, or finding a way past multi-factor authentication. The credential walks out the front door.
The downstream consequences vary by what the connected service can do. A leaked SMTP credential gets used for two things in practice. The first is sending phishing mail that appears to come from the business, which lands in the inbox of customers, vendors, and employees with full DMARC and DKIM alignment because the mail is genuinely being sent through the legitimate provider. The second is sending password-reset emails to email addresses the attacker controls, then using the resulting reset links to take over accounts. Neither attack requires touching the website’s own server or admin panel. Both of them look perfectly legitimate from the receiving end until the recipient notices that the request is unexpected.
The CRM and webhook side of the same leak is the part that bleeds beyond the website. When the SMTP plugin is wired into a CRM through a webhook or an API integration, the same stored credential can be used to read incoming lead data, impersonate the webhook source, or write fake records into the CRM. A small business that uses the website to capture leads and route them into a sales platform is now dealing with the possibility that the attacker has been reading those leads since the leak window opened. The CRM logs may not flag anything unusual because the requests are arriving with valid credentials from an expected source. The same managed email-security and spam-protection layer that watches the office inbox does not naturally watch what is happening on the website’s mail provider side, because the two stacks are technically separate even though the credentials connect them.
What Should You Check On Your Site This Week?
The remediation is a four-step sequence, and the order matters. The first step is confirming whether the plugin is installed on the site at all. A WordPress admin can see the installed plugin list under Plugins in the dashboard. An owner who does not have admin access can ask the IT provider or the original web developer to confirm the plugin name and the installed version. The plugin is sold under more than one brand name in some regions, so the easier check is searching the installed plugin slugs for the string smtp and confirming the publisher. If the version number is 2.1.4 or older, the site is in the vulnerable range. If the version is 2.1.5 or newer, the patch is already in place.
The second step is updating the plugin to the current version, which is a one-click operation from the WordPress dashboard for any site with admin access. Sites running on managed WordPress hosting that has auto-updates turned on may have received the patch already. Sites that have automatic updates disabled (a common posture on business-critical sites where every update is reviewed before it ships) need the update applied manually this week. The patch itself does not require a restart, downtime, or any configuration change. It replaces the vulnerable file and the issue is closed for any new requests.
The third step is the one most sites will skip and should not. The patch closes the future exposure. It does not invalidate the API keys that may have been leaked during the window the bug was open. Any business that ran a vulnerable version on a public-facing site for any period before the patch should rotate every credential the plugin has access to. That means logging into the connected mail provider, generating a new API key, pasting it into the now-patched plugin, and revoking the old key. The same rotation should happen for any CRM integration, webhook, or transactional-mail service the plugin touches. Skipping this step leaves the attacker with a working credential even after the underlying bug is closed.
The fourth step is a brief log review. The connected mail provider almost always exposes a sending log that shows when mail was sent, what addresses it was sent to, and which API key authorized it. An IT provider can scan that log for outbound mail from unexpected times, unexpected recipient patterns, or volumes that do not match the business’s normal contact-form traffic. A few hours of unusual sending activity in the past two weeks is the most useful single signal that the leak was actually exploited against this specific site. Compensating controls such as multi-factor authentication on every administrative interface the connected services expose reduce the long-tail risk that the attacker pivots from the leaked SMTP key into the provider dashboard itself.
Why Is This A Managed IT Job And Not A Marketing Job?
The historical division of labor at a small business puts the website under marketing and the office network under IT, and that division made sense when the website was a brochure and the network was where the real systems lived. The division stopped making sense the moment the website started holding the credentials to the office mail, the CRM, the e-commerce backend, the payment processor, the calendar, the helpdesk, and the document storage. A modern small-business website is a credential vault for the entire business, and the people who own credential hygiene are the people who own IT. The marketing team is still the right owner for the content, the design, the copy, the campaign tracking, and the day-to-day editorial work. The plugins, the keys, the rotation cadence, and the incident response when a plugin like this one ships a bug belong with the same team that owns the office’s ongoing cybersecurity monitoring and compliance work.
The practical signal that the division has not been redrawn yet is what happens when a story like this week’s surfaces. A small business with a working IT-owned plugin hygiene program will get a short note from the provider within a business day or two: which sites are exposed, what was patched, which keys were rotated, what the sending logs show. A small business without that program will hear about the story from a customer or a journalist later in the month, after the leaked keys have been used to send phishing mail under the business’s own domain. The difference is not the size of the business or the budget. The difference is whether somebody on the IT side owns the website plugins as part of the standard asset inventory.
The same inventory question scales to every other plugin on the site. The Gravity SMTP bug is one example of a broader pattern. Any WordPress plugin that stores credentials for a connected service (analytics, forms, payments, social sharing, lead-routing, backup, security, search) is a potential credential leak the day a vulnerability lands in that plugin. A patch program that only watches the WordPress core is patching a small fraction of the actual attack surface. The plugins are where the real keys live, and the plugins are where the real updates need to land.
Frequently Asked Questions
How do I tell if my website is on WordPress in the first place?
The simplest check is to add /wp-admin to the end of the public website address. If the page loads to a login screen with the WordPress logo, the site runs on WordPress. If the page returns a 404 or redirects somewhere unrelated, the site is on a different platform. About 43 percent of all small-business websites worldwide run on WordPress, so the answer is yes more often than not, but custom-built sites, Squarespace, Wix, and Shopify are common alternatives that this particular plugin issue does not affect.
Do I need to take the website offline to apply the patch?
No. The patch is a standard WordPress plugin update that applies in seconds without taking the site offline or interrupting visitor traffic. The longer task is rotating the leaked credentials at the connected services, which is also a background operation that does not require downtime. A well-run update sequence completes in under an hour for a single site, with most of the time spent in the provider dashboards generating and pasting new keys rather than in the plugin itself.
My web developer says the site has automatic updates turned on. Am I covered?
Partially. Automatic updates close the underlying bug on the next scheduled update cycle, which is typically within hours to a few days of the patch release. They do not rotate the leaked API keys. A site that automatically applied the patch is no longer vulnerable to new attacks, but the credentials that may have leaked during the disclosure window are still valid until somebody manually rotates them. Treat the patch and the rotation as two separate tasks. The patch is the door. The rotation is the lock.
How do I tell if my mail provider has been used to send mail I did not authorize?
Every major transactional-mail provider exposes a sending log in its dashboard. The log shows the timestamp, the from address, the to address, and the size of every message the account sent. Scan the log for the past two weeks for mail sent at unusual hours, to unfamiliar recipient lists, or in volumes that exceed the site’s normal contact-form traffic. Unexpected bounces and complaint reports are another signal. If the log shows nothing unusual, the leak window probably closed before this specific site was targeted. If anything looks off, treat the account as compromised and rotate every credential connected to it.
Is this a one-time problem or should I expect more plugin vulnerabilities like it?
More are coming. The WordPress plugin ecosystem has tens of thousands of active plugins, and a few of them ship a serious vulnerability every month. The pattern this week is the same pattern that has repeated for years: a popular plugin ships a bug, the disclosure goes public with a patched version, attackers race to exploit unpatched sites for a few weeks, and the long tail of unpatched sites gets picked off over the following months. The defense is not chasing every individual story. It is having a managed update program for the website that treats plugin patches as scheduled maintenance rather than as fire drills.
Should I just remove the plugin instead of updating it?
Only if the site does not need the functionality the plugin provides. Removing the plugin closes the immediate exposure but breaks any contact-form mail, password resets, or transactional notifications that depend on it. For most small-business sites, the mail delivery the plugin handles is genuinely necessary, so the right answer is to update rather than remove. If the site was set up with the plugin years ago and nobody knows what it does anymore, the right move is to ask the IT provider to map which forms and workflows depend on it before deciding whether to remove it or keep and update it.
Does my cyber-insurance policy require me to disclose this to the carrier?
It depends on the policy and on whether the site was actually breached versus exposed. Most modern policies require notification within a defined window (often 48 or 72 hours) of confirming a breach, and exposure of a credential that controls business communications usually counts as a breach event under the policy definition. A site that confirms unauthorized mail in the sending logs probably triggers the notification clause. A site that patches and rotates without any evidence of exploitation usually does not, but the right answer is to read the actual policy or call the broker rather than guess. The cost of an unnecessary notification is small. The cost of a missed-deadline notification can be the entire claim.
When Should You Bring In Outside Help?
If the website is on WordPress, the original developer is no longer on retainer, the IT provider has never been asked to inventory the site’s plugins, and nobody can answer the question of which API keys live in which plugin settings, this week is the right week to get all of that documented. A site that gets caught in the next round of plugin vulnerabilities without that documentation in place will eat a multi-day response cycle figuring out the basics. A site that has the inventory already takes the same incident in under an hour. The Gravity SMTP bug is a useful forcing function for a small business that has been meaning to formalize its website-plugin hygiene anyway. Once the inventory exists, the next bug becomes a routine update instead of an emergency. Talk to the O&O Systems team to get the inventory built before the next plugin story lands.