Una única solicitud sin autenticación revela credenciales operativas
En el tejido invisible que sostiene decenas de miles de sitios web, una grieta silenciosa permitió que cualquier visitante anónimo extrajera las llaves maestras del correo electrónico de organizaciones enteras. El fallo CVE-2026-4020 en el complemento Gravity SMTP para WordPress —presente en unas 100.000 instalaciones activas— dejó expuestas credenciales de servicios como Amazon SES, Google y Mailjet sin requerir contraseña, cuenta ni rastro evidente. Wordfence bloqueó más de 17 millones de intentos de explotación antes de que se publicara el parche en la versión 2.1.5, pero la magnitud real del daño permanece, como tantas veces ocurre en la seguridad digital, fuera del alcance de cualquier medición.
- Un único comando GET sin autenticación bastaba para obtener un informe de 365 kilobytes con claves API, tokens OAuth y detalles completos de la infraestructura del sitio.
- Investigadores de CrowdSec detectaron explotación activa desde el 27 de mayo, identificando 412 direcciones IP distintas en apenas días, en una campaña automatizada e indiscriminada.
- Wordfence registró más de 17 millones de intentos bloqueados, pero esa cifra solo refleja los sitios bajo su protección, dejando sin respuesta cuántas credenciales fueron robadas en silencio.
- Con claves de correo comprometidas, los atacantes pueden suplantar la identidad de organizaciones legítimas, explotar su reputación de dominio y usar el inventario de plugins para lanzar ataques encadenados.
- Los administradores deben actualizar a la versión 2.1.5, regenerar todas las credenciales de correo y revisar los registros de acceso en busca de solicitudes al endpoint vulnerable antes de asumir que sus sistemas están a salvo.
Un fallo en Gravity SMTP, complemento de WordPress utilizado por unas 100.000 instalaciones activas, fue explotado masivamente para robar credenciales de correo electrónico. El complemento, desarrollado por Gravity Forms, conecta sitios web con proveedores externos como Amazon SES, Google, Mailjet y Zoho, convirtiéndose en pieza central de la infraestructura de comunicaciones de muchas organizaciones. La vulnerabilidad, registrada como CVE-2026-4020, afectó todas las versiones hasta la 2.1.4 y fue corregida en la 2.1.5.
El problema residía en un endpoint de API diseñado para funciones de prueba interna. En las versiones vulnerables, la verificación de autorización siempre devolvía un resultado positivo, permitiendo que cualquier persona —sin cuenta ni contraseña— consultara el endpoint con una simple solicitud GET. La respuesta era un informe JSON de unos 365 kilobytes que incluía la versión de PHP, la configuración de la base de datos, los plugins activos y, de forma crítica, las claves API, secretos y tokens OAuth configurados para las integraciones de correo. La explotación no dejaba más rastro que una entrada en los registros del servidor web, fácilmente ignorada entre el tráfico habitual.
Investigadores de CrowdSec comenzaron a observar explotación activa el 27 de mayo. Para el 1 de junio habían identificado 412 direcciones IP distintas, caracterizando la actividad como un escaneo automatizado e indiscriminado. Wordfence, por su parte, reportó haber bloqueado más de 17 millones de intentos, aunque esa cifra solo refleja los sitios bajo su protección. Cuántas credenciales fueron efectivamente robadas en sistemas desprotegidos sigue siendo una incógnita.
Las consecuencias de una credencial comprometida son amplias: un atacante puede enviar correos suplantando a la organización legítima, aprovechar su reputación de dominio y usar el inventario de plugins expuesto para identificar nuevas vulnerabilidades. La respuesta exigida es inmediata: actualizar a la versión 2.1.5, regenerar todas las credenciales en cada proveedor de correo conectado y revisar los registros de acceso en busca de solicitudes al endpoint /wp-json/gravitysmtp/v1/tests/mock-data. Una discrepancia en las puntuaciones de severidad —5.3 según Wordfence frente a 7.5 en la base de datos nacional de vulnerabilidades— no altera la urgencia: con explotación activa y credenciales operativas en juego, la actualización no admite demora.
A flaw in Gravity SMTP, a widely used WordPress plugin, has been actively exploited to steal email credentials from tens of thousands of websites. Wordfence, a security firm that monitors WordPress threats, reported blocking more than 17 million exploitation attempts as of mid-June. The vulnerability, tracked as CVE-2026-4020, affects all versions of the plugin up to 2.1.4 and was patched in version 2.1.5.
Gravity SMTP, built by Gravity Forms, runs on approximately 100,000 active WordPress installations. The plugin's purpose is straightforward: it connects a WordPress site to external email providers—services like Amazon SES, Google, Mailjet, Resend, and Zoho—so that websites can send notifications, form submissions, and transactional messages reliably. For many site operators, it's an essential piece of infrastructure. The vulnerability turns that infrastructure into a liability.
The flaw lives in an API endpoint designed for internal testing functions. In vulnerable versions, the authorization check that should prevent unauthorized access always returns a positive result. This means anyone, logged in or not, can query the endpoint. A single unauthenticated GET request with a specific parameter causes the server to return a JSON report roughly 365 kilobytes in size. That report contains the site's PHP version, WordPress version, web server details, active plugins and their versions, the active theme, database configuration, and table names. It also includes the API keys, secrets, and OAuth tokens configured for email integrations. Exploitation requires no authentication, no file modification, no account creation—just one simple request. This stealth is dangerous: the only trace left behind would be an entry in the web server's access logs, easily overlooked in the noise of normal traffic.
The exposure of email credentials opens multiple attack vectors. An attacker with stolen API keys or OAuth tokens can impersonate the legitimate organization, sending messages through its email account and using its domain reputation. The attacker could also harvest the list of installed plugins and their versions, using that information to identify other vulnerabilities for follow-up attacks. Security researchers at CrowdSec began observing active exploitation on May 27. By June 1, they had identified 412 distinct IP addresses attempting to exploit the flaw. They characterized the activity as automated internet traffic rather than a targeted campaign, suggesting the vulnerability was being scanned and attacked indiscriminately across the web.
Wordfence's block count—17 million attempts—measures only the traffic it detected and stopped on sites it protects. The actual scope of exposure is unknowable: the figure does not reveal how many unprotected sites were attacked, how many requests reached vulnerable systems, or how many credentials were successfully stolen. The uncertainty itself is part of the threat.
The response is clear but demanding. Site administrators must update Gravity SMTP to version 2.1.5 or later immediately. Anyone who ran a vulnerable version with email integrations configured should assume their API keys, secrets, and tokens are compromised. After updating, they must regenerate those credentials through each connected email provider. They should also search their web server access logs for requests to the endpoint /wp-json/gravitysmtp/v1/tests/mock-data, paying special attention to requests containing the parameter ?page=gravitysmtp-settings. Additionally, administrators should review activity logs from their email providers for unfamiliar sends, logins, or authentication attempts.
A discrepancy in severity ratings adds a note of complexity. Wordfence assigned the vulnerability a CVSS score of 5.3 out of 10, marking it as medium severity. The National Vulnerability Database and GitHub's advisory database list it as 7.5, classifying it as high. The difference does not change the affected versions or the urgency of the recommendation. Active exploitation combined with the exposure of operational credentials means this flaw demands immediate attention regardless of how security researchers score it.
Notable Quotes
La explotación requiere una única solicitud GET sin autenticación y como no necesita modificar archivos ni crear cuentas, puede no producir las señales que habitualmente se buscan al investigar una intrusión.— Wordfence
Los administradores que utilizaron una versión vulnerable con integraciones de correo configuradas deberían considerar que las claves API, secretos y tokens podrían haber quedado expuestos.— Wordfence
The Hearth Conversation Another angle on the story
Why would someone build an endpoint that returns this much sensitive information without any authentication?
It was designed for internal testing—developers needed a way to verify that email integrations were working correctly. The assumption was that only trusted administrators would access it. But the authorization check failed, leaving the door open to anyone.
So a single request reveals everything about a site's infrastructure?
Everything. Plugins, versions, database structure, email provider credentials. It's like handing an attacker a detailed blueprint of the site's technical setup and the keys to its email system.
How many sites do we actually know were compromised?
We don't. Wordfence blocked 17 million attempts, but that's only traffic they saw. Unprotected sites could have been hit without anyone knowing. The real number of stolen credentials is invisible.
If I'm running this plugin, what's my first move?
Update immediately to 2.1.5 or later. Then assume your email credentials are exposed and regenerate them through every provider you use. Check your server logs and email provider logs for signs of unauthorized access.
How long has this been exploited?
Active exploitation started at least by late May, possibly earlier. The attack accelerated in early June, with millions of attempts blocked in a single day. By the time Wordfence published their alert on June 17, the vulnerability had been under active attack for weeks.
Does the patch fix the authorization check?
Yes. Version 2.1.5 corrects the logic so that the endpoint properly validates whether a request is authorized. Without that fix, the endpoint remains wide open.