CVE-2026-4020: Gravity SMTP Secrets Disclosure and IOCs
Hey team,
With the active exploitation of CVE-2026-4020 in the Gravity SMTP plugin, I wanted to share some quick detection logic. We're seeing this being used to siphon SMTP credentials and OAuth tokens, which leads to some serious phishing campaigns downstream if not rotated immediately.
The flaw (CVSS 5.3) allows unauthenticated users to hit a specific endpoint and dump configuration data. If you have this plugin on any of your WP instances, treat it as a breach.
Here is a quick WP-CLI check to find vulnerable versions (assuming < 1.2.1 was the patch, check vendor specifics for exact versioning):
wp plugin list --name=gravity-smtp --field=version --allow-root
If you are looking in your logs, the exploitation attempts usually target the REST API. You can grep your access logs for suspicious activity patterns on the plugin namespace:
grep "GET /wp-/gravity-smtp" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr
Has anyone seen specific IOCs related to the post-exploitation abuse of these SMTP credentials yet? I'm specifically looking for User-Agent patterns or header anomalies associated with the attackers leveraging the stolen mailer configs.
Let's secure those inboxes!
Good catch on the logs. We've blocked the specific REST endpoint at the WAF level as a temporary mitigation for clients lagging on updates. We've noticed the requests often originate from residential proxies, probably to bypass geo-blocking. Here's a snippet for ModSec if anyone needs it:
apache SecRule REQUEST_URI "@beginsWith /wp-/gravity-smtp" "id:1001,deny,status:403,msg:'Gravity SMTP Block'"
We caught this on a client site yesterday. The attacker didn't just take the SMTP creds; they used the logged OAuth tokens to tamper with other connected integrations. Even if you patch, you must revoke the OAuth tokens exposed in that config dump. Patching stops the leak, but it doesn't invalidate the stolen keys.
From a SOC perspective, this is a great reminder to monitor for 'Successful Login' anomalies on your mail servers. If you see a spike in auth attempts or email volume from a WordPress host that usually sits idle, that's your secondary indicator. We're using this KQL query in Sentinel:
DeviceNetworkEvents
| where RemotePort == 587 and InitiatingProcessFileName has "php"
| summarize count() by SourceIP, bin(Timestamp, 5m)
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access