A vulnerability disclosed in June 2026 in the Gravity SMTP WordPress plugin illustrates a category of email security failure that DMARC was never designed to address. CVE-2026-4020 is an unauthenticated information disclosure flaw in the plugin’s REST API. An attacker who finds a WordPress site running a vulnerable version can retrieve the site’s stored email service provider API credentials in a single HTTP request, with no authentication required.
Gravity SMTP is an email delivery management plugin with more than 100,000 active WordPress installs. It integrates WordPress with third-party sending services – providers like SendGrid, Mailgun, Postmark, and Amazon SES – and stores those API credentials in the WordPress database for use whenever the site sends email. The vulnerability exposes those credentials through an endpoint that does not verify whether the requester has permission to read them.
The downstream consequence is precise: an attacker in possession of your ESP API key can send email from your domain using your own configured sending infrastructure. That email will pass SPF, pass DKIM, and pass DMARC because the authentication layer has no way to distinguish a message you sent from a message sent by someone using your stolen credentials.
What the Flaw Is and How It Works
Gravity SMTP provides WordPress with a centralized interface for managing transactional and notification email delivery. Rather than using WordPress’s built-in wp_mail() with a generic SMTP relay, the plugin lets administrators configure named connections to specific email providers, test those connections, and route different types of site-generated email through different provider accounts.
To enable these features, the plugin stores provider credentials in the WordPress options table. For most integrations, those credentials are API keys issued by the sending provider. The vulnerability – classified as an unauthenticated information disclosure – exists in a REST API endpoint the plugin registers to support its administrative UI. The endpoint is accessible without authentication, and its response includes the stored provider credentials.
An attacker who discovers a WordPress site running a vulnerable version of Gravity SMTP needs only to send a crafted HTTP GET request to a known endpoint path. The response returns the configured API keys in plaintext. The attack requires no WordPress account, no session cookie, and no social engineering. It is a one-step credential extraction from any WordPress installation that has the vulnerable plugin installed and active.
Why DMARC Cannot Detect This Attack
When you configure an email service provider account, you take several steps that tie your domain to that provider’s sending infrastructure. You add the provider’s sending IPs or hostnames to your SPF record. You configure DKIM signing, either by granting the provider permission to sign on behalf of your domain or by adding the DKIM public key to your DNS. You may set up your DMARC policy at p=reject to block any sending that does not align with those authorized sources.
All of that configuration creates a set of authentication signals that receiving servers use to verify that an incoming message claiming to be from your domain was actually sent by an authorized party. When an attacker uses your stolen API key to send through your ESP, they are an authorized party from the authentication layer’s perspective. The message originates from your ESP’s sending IPs, which are in your SPF record. The message is signed with your domain’s DKIM key, because your ESP signs all outbound messages on your behalf. The From header domain matches. DMARC evaluates all of this and issues a pass.
There is no authentication failure to detect because nothing about the authentication is failing. The credentials are real. The infrastructure is authorized. The signatures are valid. DMARC was designed to verify that a message passed through authorized infrastructure – not to verify that the person who initiated the message via an API was permitted to do so.
This is a fundamental architectural boundary of domain-level authentication: it operates at the transport and signing layer, not at the application credential layer. Once credential theft bridges those layers, authentication signals become evidence of an attack rather than a defense against it.
The Deliverability Damage Is Immediate
Beyond the direct threat of impersonation attacks, credential-based sending abuse causes collateral damage to the legitimate sender’s deliverability.
When an attacker uses a stolen ESP API key to send phishing or spam at volume, the behavior pattern of your account changes dramatically. Sending volume spikes. Recipients outside your normal list receive messages. Spam complaint rates rise. Bounce rates from invalid addresses increase. These signals feed into the reputation systems maintained by Gmail, Microsoft, and other major inbox providers – not for the attacker’s infrastructure, but for your ESP account and sending domain.
Reputation damage from a credential-abuse incident persists after the breach is remediated. Even after you rotate the compromised API key and stop the unauthorized sending, the behavioral history stays in recipient providers’ reputation systems. Deliverability recovery from a sustained credential-abuse incident can take weeks.
Organizations that do not monitor their sending behavior have no visibility into whether their ESP account is being used by someone else until inbox providers start deferring or rejecting their own legitimate mail. DMARC aggregate reports may not surface this at all if the unauthorized sending is passing authentication, because aggregate reports count authentication pass and fail rates rather than detecting anomalous behavior within passing traffic.
What Sites Using Gravity SMTP Need to Do
Update the plugin immediately. The vulnerability is in specific versions of Gravity SMTP prior to the patched release. Any WordPress site running an affected version is exposed regardless of other security configurations. WordPress plugin updates are available through the standard WordPress admin dashboard.
Rotate all API keys. Even if there is no evidence of exploitation, any site that ran a vulnerable version while publicly accessible should treat its stored ESP credentials as compromised and rotate them. Most email service providers allow credential rotation without disrupting service – new keys can be issued, configured, and tested before the old keys are revoked.
Audit your ESP account activity logs. All major email service providers maintain activity logs that record sending events, API calls, and authentication events by credential. After rotating credentials, review the activity log for the previous period. Unusual sending patterns, unexpected recipient lists, or sending events at times your site was not actively generating email are indicators of credential misuse.
Review your DMARC aggregate reports for volume anomalies. Even when credential-based sending passes DMARC authentication, aggregate reports show total sending volume by source. A spike in authenticated sending volume from your ESP that does not correspond to a known campaign or operational event is a signal worth investigating, even if the authentication status shows 100% pass.
Consider separating site notification credentials from marketing credentials. A common configuration puts all site-generated email – order confirmations, password resets, admin notifications – through the same ESP account as marketing campaigns. Separating these into distinct API keys limits the blast radius of a credential compromise: stolen plugin credentials do not automatically expose the credentials used for high-volume marketing sends, and vice versa.
The Broader Credential Supply Chain Problem
CVE-2026-4020 is one instance of a pattern that runs across the ecosystem of tools organizations use to manage email sending. WordPress plugins, CRM integrations, marketing automation platforms, and customer support tools frequently store ESP credentials in database tables or configuration files that are accessible through application-layer vulnerabilities.
DMARC enforcement protects against external parties who attempt to send email claiming to be from your domain without any access to your infrastructure. It provides no protection against an attacker who gains access to the application credentials that authorize sending through that infrastructure. The two threat categories require different defenses, and they are both live.
For organizations running email-heavy WordPress sites – e-commerce stores, SaaS products, membership platforms – the credential layer is the attack surface that authentication records in DNS cannot protect. Periodic audits of what credentials are stored in your WordPress installation, where they are used, and whether they follow least-privilege principles are the control that fills the gap DMARC leaves open.
Excello Mail gives you continuous visibility into your DMARC aggregate reports, sending sources, and volume trends across all your email streams. Sign up for free to Excello Mail and know immediately when something sends from your domain that should not be.