The Gravity SMTP plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to

CVE-2026-4020 is an unauthenticated REST API exposure in the Gravity SMTP WordPress plugin affecting all versions <= 2.1.4, fixed in 2.1.5. A request to /wp-json/gravitysmtp/v1/tests/mock-data?page=gravitysmtp-settings can return a large system report with WordPress versioning, active plugins, server details, database metadata, paths, and potentially mail-provider API keys or tokens configured in the plugin.

The vendor's 7.5 HIGH baseline is directionally right, but the reason is not pure confidentiality loss in the abstract. In practice this is a low-friction internet-facing recon primitive that can expose reusable secrets and sharply improve follow-on exploitation, while the main downward pressure is population size: Gravity SMTP is a premium plugin tied to a Gravity Forms Elite/Nonprofit license, so the exposed population is much smaller than a mass-market free SMTP plugin.

Why this verdict

• Unauthenticated remote step: no login, no user click, no internal foothold. That keeps the vendor baseline high and removes the usual 'post-initial-access only' discount.
• Active exploitation evidence: CrowdSec observed exploitation beginning 2026-05-27, and Wordfence shows meaningful blocked attack volume. Once WordPress bot traffic picks up a route like this, exposure becomes operational, not theoretical.
• Impact is often more than config trivia: the report can include mail-provider API keys/tokens plus full plugin inventory and environment details, which directly amplifies follow-on abuse.
• Population friction lowers the ceiling: Gravity SMTP is tied to a paid Gravity Forms license, so the reachable victim pool is materially smaller than free plugins with hundreds of thousands of public installs.
• Chaining requirement prevents a Critical jump: for many victims this is still reconnaissance or secret exposure that needs a second move before site takeover or tenant-wide damage.

Why not higher?

This is not direct RCE, auth bypass, or one-shot admin takeover. The worst outcomes depend on what the returned report actually contains and whether the attacker can reuse exposed secrets or chain into another weakness. The premium-plugin install base also reduces mass population compared with the free-plugin disasters that justify CRITICAL.

Why not lower?

A MEDIUM would underweight the two things defenders actually care about: it is unauthenticated over the internet, and there is now exploitation telemetry. Even when no key is exposed, the endpoint still hands attackers a precise software bill of materials and environment profile for the target, which materially increases follow-on risk.

1. Block the vulnerable REST route now — Push a CDN/WAF/reverse-proxy rule for /wp-json/gravitysmtp/v1/tests/mock-data and specifically the page=gravitysmtp-settings variant. Because there is exploitation evidence, do this immediately, within hours, not on a monthly rules cycle.
2. Rotate exposed mail-provider secrets — If the endpoint was reachable from the internet at any time, assume connector API keys and tokens may have been exposed and rotate SendGrid/Mailgun/Postmark/Brevo/O365 credentials the same day. This closes the most damaging follow-on path even before all sites are patched.
3. Constrain public wp-json exposure where feasible — Use origin ACLs, bot management, or route-level policy to reduce unauthenticated access to unnecessary REST paths while preserving application functionality. Apply as an emergency risk reduction measure within hours for internet-facing estates that cannot patch immediately.
4. Review web and provider logs for this exact path — Search CDN, reverse-proxy, and web-server logs for requests to the vulnerable path and correlate with outbound email-provider usage anomalies. Start triage immediately, within hours, because exploitation is already being automated.
5. Disable or remove the plugin where unused — If Gravity SMTP is dormant, duplicated by another mail plugin, or only present on templates, remove the reachable surface entirely. For HIGH with exploitation evidence, complete this cleanup as soon as practical, starting now.

Run this from an auditor workstation, bastion, or CI runner that can reach the target site over HTTPS. Invoke it as bash check-cve-2026-4020.sh https://example.com; no credentials are required, and no privileged access is needed because the test only performs a safe GET against the public REST path.

#!/usr/bin/env bash
# check-cve-2026-4020.sh
# Detects likely exposure for CVE-2026-4020 on a public WordPress site.
# Usage: bash check-cve-2026-4020.sh https://example.com
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

set -u

if [ $# -ne 1 ]; then
  echo "Usage: $0 https://example.com"
  exit 3
fi

BASE="$1"
BASE="${BASE%/}"
URL="$BASE/wp-json/gravitysmtp/v1/tests/mock-data?page=gravitysmtp-settings"
TMP_BODY="$(mktemp)"
trap 'rm -f "$TMP_BODY"' EXIT

HTTP_CODE=$(curl -ksS -A "noisgate-cve-check/1.0" -m 20 -o "$TMP_BODY" -w "%{http_code}" "$URL")
CURL_RC=$?

if [ $CURL_RC -ne 0 ]; then
  echo "UNKNOWN - request failed to $URL"
  exit 2
fi

BODY_SIZE=$(wc -c < "$TMP_BODY" | tr -d ' ')

# Heuristics based on public advisories: vulnerable responses can be large JSON reports
# containing WordPress/system metadata and plugin inventory.
if [ "$HTTP_CODE" = "200" ]; then
  if grep -Eqi 'wordpress|active plugins|document root|database|php version|loaded extensions|theme' "$TMP_BODY"; then
    echo "VULNERABLE - endpoint returned identifiable system report content (HTTP 200, ${BODY_SIZE} bytes)"
    exit 1
  fi

  if [ "$BODY_SIZE" -ge 50000 ]; then
    echo "VULNERABLE - endpoint returned unusually large data consistent with exposed report (HTTP 200, ${BODY_SIZE} bytes)"
    exit 1
  fi

  if grep -Eq '^[[:space:]]*\{' "$TMP_BODY"; then
    echo "UNKNOWN - endpoint returned JSON but did not match strong report indicators (HTTP 200, ${BODY_SIZE} bytes)"
    exit 2
  fi
fi

if [ "$HTTP_CODE" = "401" ] || [ "$HTTP_CODE" = "403" ] || [ "$HTTP_CODE" = "404" ]; then
  echo "PATCHED - endpoint not publicly exposed in a vulnerable way (HTTP $HTTP_CODE)"
  exit 0
fi

if [ "$HTTP_CODE" = "200" ]; then
  echo "PATCHED - no strong signs of the vulnerable report were returned (HTTP 200, ${BODY_SIZE} bytes)"
  exit 0
fi

echo "UNKNOWN - unexpected HTTP status $HTTP_CODE from $URL"
exit 2

Sources

1. NVD CVE-2026-4020
2. Wordfence vulnerability record for CVE-2026-4020
3. Gravity SMTP changelog
4. Gravity SMTP product page
5. Patchstack advisory
6. CISA Known Exploited Vulnerabilities Catalog
7. CrowdSec exploitation tracking report
8. ProjectDiscovery Nuclei templates releases