Los piratas informáticos aprovechan el error del complemento Gravity SMTP de WordPress para exponer las claves API – CYBERDEFENSA.MX

Los actores de amenazas están explotando una falla de seguridad recientemente reparada que afecta a Gravity SMTP, un complemento de WordPress que está instalado en alrededor de 100.000 sitios.

La vulnerabilidad, rastreada como CVE-2026-4020 (Puntuación CVSS: 5,3), es una falla de divulgación de información de gravedad media que puede permitir a atacantes no autenticados extraer datos confidenciales, como datos de configuración, claves API, secretos y tokens OAuth configurados para las integraciones de correo electrónico del complemento.

«Esto se debe a un punto final de la API REST registrado en /wp-json/gravitysmtp/v1/tests/mock-data con un permiso_callback que incondicionalmente devuelve verdadero, permitiendo que cualquier visitante no autenticado acceda a él», Wordfence dicho.

Ciberseguridad

«Cuando se agrega el parámetro de consulta ?page=gravitysmtp-settings, el método Register_connector_data() del complemento completa los datos del conector interno, lo que hace que el punto final devuelva aproximadamente 365 KB de JSON que contiene el informe completo del sistema».

Como resultado, un atacante no autenticado puede utilizar este problema como arma para recuperar una amplia gama de información, que incluye:

  • versión PHP
  • Extensiones cargadas
  • Versión del servidor web
  • Ruta raíz del documento
  • Tipo y versión del servidor de base de datos
  • Versión de WordPress
  • Todos los complementos activos con versiones.
  • Tema activo
  • Detalles de configuración de WordPress
  • Nombres de tablas de base de datos
  • Claves/tokens API configurados en el complemento, como Amazon SES, Google, Mailjet, Resend y Zoho

Luego, los atacantes podrían aprovechar esta exposición para recopilar credenciales que podrían usarse de forma abusiva para enviar correos electrónicos en nombre del sitio, así como obtener detalles extensos de la pila de software del sitio, que podría actuar como base para ataques posteriores.

«Como ocurre con todas las vulnerabilidades de exposición de información confidencial, el impacto depende de los datos que estén expuestos», añadió Wordfence. «En este caso, la exposición de credenciales API de terceros en vivo significa que un atacante podría abusar de los servicios de correo electrónico conectados al sitio, mientras que el informe detallado del sistema reduce significativamente el esfuerzo requerido para planificar futuros ataques contra el sitio».

Se lanzó un parche para la vulnerabilidad en la versión 2.1.5 del complemento. Los malos actores ya se han aprovechado del defecto enviando solicitudes HTTP GET no autenticadas al punto final vulnerable de la API REST con el parámetro de consulta «?page=gravitysmtp-settings», lo que hace que el servidor devuelva información valiosa sobre el sitio sin requerir ninguna autenticación.

Ciberseguridad

Wordfence ha bloqueado más de 17 millones de intentos de explotación dirigidos a CVE-2026-4020 hasta la fecha, y la actividad inicial comenzó a principios de mayo de 2026 antes de aumentar drásticamente alrededor del 6 de junio de 2026, alcanzando un máximo de más de 4.000.000 de solicitudes un día después. Los esfuerzos de explotación se originaron en las siguientes direcciones IP:

  • 45.148.10.95
  • 193.32.162.60
  • 176.65.148.139
  • 173.199.90.188
  • 45.148.10.120
  • 185.8.107.155
  • 185.8.106.37
  • 185.8.106.92
  • 185.8.106.145
  • 176.65.148.30

Los propietarios de sitios que ejecutan una versión vulnerable del complemento Gravity SMTP y han configurado integraciones de correo electrónico de terceros deben asumir el compromiso y rotar las credenciales después de actualizar el complemento a la última versión lo antes posible. También se recomienda revisar los archivos de registro del servidor en busca de solicitudes que se originen en las direcciones IP antes mencionadas para detectar cualquier solicitud sospechosa al punto final de la API.

PCPJack secuestra 230 servidores AWS, Google Cloud y Azure para una red de retransmisión SMTP encubierta – CYBERDEFENSA.MX

El actor de amenazas conocido como PCPJack ha secuestrado servidores en la nube asociados con Amazon Web Services (AWS), Google Cloud y Microsoft Azure para crear una red encubierta de retransmisión de correo electrónico SMTP.

«Los servidores empresariales comprometidos en EE. UU., Europa y Asia se convirtieron silenciosamente en servidores proxy SMTP, se verificó su capacidad de retransmisión de correo y se sincronizaron con un consumidor intermedio cada cinco minutos», dijo Hunt.io en un comunicado. «La infraestructura todavía estaba funcionando cuando la encontramos».

La empresa de inteligencia de amenazas dicho encontró código fuente, archivos binarios compilados, registros de estado de implementación, escáneres de Internet, herramientas de explotación y una configuración de Sliver en vivo después de que el actor de amenazas detrás de la operación dejó dos directorios abiertos en un servidor de comando y control (C2) («213.136.80[.]73») sin ninguna autenticación.

PCPJack fue descubierto por primera vez por SentinelOne en abril de 2026 después de que identificó un marco de robo de credenciales que apunta específicamente a los servicios en la nube, mientras tomaba medidas para terminar y eliminar procesos o artefactos asociados con TeamPCP, otro notorio grupo de piratería que ha llamado la atención en los últimos meses por sus ataques a la cadena de suministro de software.

Ciberseguridad

Organizado en uno de los directorios abiertos. Astilla-Kit de herramientas de implementación de proxy SMTP integrado, junto con tunelización Chisel y binarios de proxy para la mayoría de las arquitecturas de CPU de Linux, como AMD64, ARM64 y x86. En el lado de la víctima, el binario se elimina como un archivo oculto con prefijo de punto y se conserva en «/var/tmp/.xs».

También se encuentran en los directorios scripts de implementación diseñados para cargar la configuración del cliente Sliver C2 y filtrar las balizas de Linux que se han registrado en los últimos diez minutos. Las balizas son implantes que llaman periódicamente al servidor C2 a intervalos regulares para registrarse y recuperar comandos.

«Cada baliza recibe un puerto proxy SOCKS5 derivado de manera determinista de un hash MD5 de su UUID Sliver, asignado en el rango 10000-14999», señaló Hunt.io. «La misma baliza siempre se asigna al mismo puerto en todas las ejecuciones, lo que elimina la necesidad de un registro de puerto compartido».

El script también es capaz de ejecutar una puerta de calidad SMTP que busca acceso saliente a smtp.gmail.[.]Com:587. Los hosts que no pasan esta verificación se omiten con un código de salida de cero.

«Esta puerta define el propósito de la operación: los hosts que no pueden transmitir correo electrónico no tienen ningún valor para este canal», añadió la empresa de ciberseguridad. «Las balizas se procesan en lotes de 50, con una espera de 25 minutos después de la carga y 15 minutos después de la ejecución de los comandos, para dar cabida a registros de balizas a intervalos lentos».

Se ha descubierto que las iteraciones posteriores de los scripts de implementación eliminan la puerta SMTP y la lógica de procesamiento por lotes. También está presente un script de diagnóstico que selecciona cinco balizas activas y les asigna a cada una un comando de shell que verifica lo siguiente:

  • Presencia de archivos binarios de Chisel en rutas de caída conocidas
  • Se está ejecutando un proceso de Chisel
  • Espacio en disco
  • Accesibilidad del puerto 9000 en el C2, y
  • Presencia de artefactos de persistencia, como la entrada cron o el servicio systemd
Ciberseguridad

Además, el servidor C2 ejecuta un script Python llamado «chisel_verifier.py» como un demonio en segundo plano persistente, que enumera los puertos activos del túnel Chisel a través de ss -tlnp cada 60 segundos, prueba la capacidad SMTP de cada nuevo puerto y elimina los túneles fallidos o descartados del grupo activo.

Los proxies verificados se enriquecen con la dirección IP de salida, el país y el ASN a través de servicios como api.ipify.[.]org y ip-api[.]com. Luego, las listas de proxy se sincronizan cada cinco minutos a través del Protocolo de copia segura (SCP) con un servidor descendente independiente en 38.242.204.[.]245. Actualmente no se puede acceder al servidor. El objetivo final de la operación aún no está claro en este momento.

«El resultado de 230 nodos es el resultado observable. Si esta progresión refleja un solo operador iterando o múltiples actores que comparten la misma infraestructura no se puede determinar a partir de los archivos recuperados», dijo Hunt.io, describiéndola como una campaña oportunista.

«La lista de proxy verificada se sincroniza cada cinco minutos con ese servidor y alguien la está consumiendo. Ya sea para spam, phishing o cualquier otra cosa, la infraestructura para realizar entregas a escala claramente estaba funcionando».