CVE-2026-6675 WordPress es una vulnerabilidad de email relay abierto en el plugin Responsive Blocks – Page Builder for Blocks & Patterns, versiones hasta 2.2.0 incluida. Publicada el 21 de abril de 2026, permite que cualquier atacante no autenticado envíe emails arbitrarios a través del servidor de correo de tu sitio WordPress, sin necesidad de credenciales ni interacción del usuario.
En 30 segundos
- Qué es: vulnerabilidad en Responsive Blocks ≤ 2.2.0 que convierte tu WordPress en servidor de spam abierto
- CVSS: 5.3 (medio), sin autenticación requerida, acceso por red
- Impacto real: tu dominio puede quedar en listas negras de spam y perder deliverability de emails legítimos
- Solución: actualizar a versión 2.2.1 o posterior — disponible desde abril 2026
- Urgencia: si usás el plugin y no actualizaste, desactivalo ahora mientras preparás el parche
Wordfence es un plugin de WordPress desarrollado por Wordfence, Inc., que implementa un firewall de aplicación web para detectar malware y amenazas de seguridad. Incluye herramientas de protección y recuperación ante incidentes.
Qué es CVE-2026-6675: vulnerabilidad de email relay abierto
CVE-2026-6675 es una vulnerabilidad de tipo Unauthenticated Open Email Relay en el plugin Responsive Blocks – Page Builder for Blocks & Patterns para WordPress. Afecta todas las versiones hasta 2.2.0 incluida y fue publicada el 21 de abril de 2026 según el registro de INCIBE-CERT.
Un email relay abierto es básicamente dejar la puerta del correo de tu servidor sin llave. Cualquiera puede entrar y mandar emails usando tu infraestructura, como si fueran tuyos. El destinatario recibe un mensaje que sale de tu dominio, con tu IP, con tus cabeceras SMTP. Vos no sabés nada hasta que Gmail o Hotmail te ponen en cuarentena y tus emails de facturación dejan de llegar.
La puntuación CVSS v3.1 es 5.3 (medium), con vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. El dato más importante de ese vector: PR:N y UI:N, que significa cero privilegios necesarios y sin interacción del usuario. Cualquiera con acceso a internet puede explotar esto contra tu sitio.
Cómo funciona la vulnerabilidad: el parámetro email_to sin validar
Ponele que alguien descubre que tu sitio tiene Responsive Blocks instalado. Lo único que necesita hacer es mandar un POST request a la ruta pública de la REST API del plugin. El endpoint no pide autenticación. El parámetro email_to acepta cualquier dirección. No hay is_email() con validación de dominio, no hay whitelist, no hay check de current_user_can().
El flujo es así de simple: atacante envía POST con email_to=victima@ejemplo.com, WordPress procesa la solicitud, la función de envío de correo del plugin toma ese parámetro directo y manda el email. Tu servidor SMTP lo entrega porque viene de una fuente autorizada (vos). La víctima recibe un email que parece legítimo de tu dominio.
La causa raíz es doble según el código fuente del plugin en el repositorio oficial: falta de autorización (el endpoint es accesible sin autenticación) más falta de validación de inputs en el lado del servidor para el campo de destinatario. Dos fallas independientes, las dos necesarias para el exploit, las dos presentes hasta la versión 2.2.0.
Qué versiones están afectadas y cómo verificar la tuya
Todas las versiones del plugin hasta 2.2.0 inclusive son vulnerables. La versión 2.2.1 incorpora el parche. Esto se conecta con lo que analizamos en implementar protección DDoS en WordPress.
Para ver qué versión tenés instalada, entrá a tu admin WordPress, navegá a Plugins → Plugins instalados, buscá «Responsive Block Editor Addons» o «Responsive Blocks» y fijate el número de versión que aparece debajo del nombre. Si dice 2.2.0 o cualquier número menor, el sitio está expuesto.
Podés verificarlo también por wp-cli si tenés acceso SSH:
wp plugin list --name=responsive-block-editor-addons --fields=version
Un resultado de 2.2.0 o menor confirma la vulnerabilidad. La solución definitiva es 2.2.1 o posterior.
Riesgos concretos: de phishing masivo a blacklist del dominio
El riesgo no termina en «te mandan spam desde tu servidor». Según el análisis de WP Firewall sobre este CVE, las consecuencias posibles incluyen:
| Tipo de abuso | Impacto en tu sitio |
|---|---|
| Spam masivo | Tu IP/dominio entra en listas negras SMTP (Spamhaus, Barracuda, etc.) |
| Phishing dirigido | Correos que parecen de tu empresa llegan a clientes o empleados |
| Distribución de malware | Adjuntos maliciosos enviados bajo tu identidad |
| Daño a deliverability | Tus emails legítimos (facturas, notificaciones) van directo a spam |
| Compromiso de cuentas | Links de reset de password falsos enviados desde tu dominio legítimo |
El peor escenario no es técnico: es el reputacional. Una vez que tu dominio queda en una blocklist como Spamhaus DBL, sacarlo puede llevar semanas de gestión con cada proveedor de email por separado. Mientras tanto, los emails que mandás a clientes no llegan. ¿Y qué le decís al cliente? ¿Qué un plugin mal parcheado bloqueó tus comunicaciones? Exacto, no es una conversación cómoda.
Paso a paso: cómo mitigar CVE-2026-6675
Paso 1: desactivar el plugin (medida temporal inmediata)
Si no podés actualizar de inmediato, desactivá el plugin ahora. Eso cierra el endpoint vulnerable.
Desde el admin: Plugins → Plugins instalados → Responsive Block Editor Addons → Desactivar.
Por wp-cli: wp plugin deactivate responsive-block-editor-addons
Eso sí: esto no es una solución permanente si usás los bloques del plugin en tu contenido. Las páginas que dependan de esos bloques pueden verse afectadas. Tomalo como medida puente mientras ejecutás el paso 2. Para más detalles técnicos, mirá soluciones de seguridad más robustas.
Paso 2: actualizar a versión 2.2.1 (solución definitiva)
El proceso recomendado, si el sitio está en producción:
- Backup completo antes de tocar nada (base de datos + archivos). Si usás WPVivid, generá un backup manual desde el panel.
- Probar en staging si tenés un entorno de prueba disponible.
- En el admin, ir a Plugins → Actualizaciones disponibles y actualizar Responsive Block Editor Addons a 2.2.1+.
- Verificar que tus páginas y layouts con bloques del plugin siguen funcionando correctamente.
- Revisá los logs de error de WordPress para detectar conflictos post-actualización.
El parche en 2.2.1 introduce validación del campo de email con is_email(), verificación de autorización en el endpoint REST, y restricciones sobre los destinatarios válidos. Los cambios están documentados en el repositorio de plugins de WordPress.org.
Monitoreo post-parche: qué revisar en tus logs
Actualizar el plugin no borra el historial. Si el sitio estuvo expuesto, hay que ver si alguien aprovechó la ventana.
En los logs de acceso del servidor (Apache o Nginx), buscá POST requests a rutas que contengan /wp-json/responsive-block-editor-addons/. Una cantidad inusual de estas peticiones, especialmente desde IPs desconocidas o rangos automatizados, es señal de que el endpoint fue explorado o explotado.
En los logs SMTP o de correo saliente, revisá si hay emails enviados a dominios extraños, en volúmenes inusuales, o fuera del horario habitual de tu sitio. Muchos hostings tienen acceso a logs de correo desde el panel de control.
Para verificar si tu dominio terminó en listas negras, usá MXToolbox Blacklist Check con tu dominio o IP de servidor. Si aparece en alguna lista, el proceso de remoción varía por blocklist pero en general requiere solicitar la deslistación una vez que el problema está resuelto.
Prevención futura: lecciones para plugins y administradores
Esta vulnerabilidad es un recordatorio de algo que los desarrolladores de plugins de WordPress repiten como error demasiado seguido: exponer endpoints REST sin verificar autorización ni validar inputs.
Para desarrolladores que mantienen plugins propios o custom, los tres controles mínimos en cualquier endpoint REST que envíe emails son: validar el formato con is_email(), restringir el acceso con current_user_can() o un permission callback apropiado, y definir una whitelist de dominios de destino si el caso de uso lo permite. Complementá con aplicar parches de seguridad críticos.
Para administradores de WordPress: mantenés el sitio actualizado. Suena obvio, pero la realidad es que muchos sitios quedan con plugins en versiones viejas por miedo a romper compatibilidad. Una estrategia razonable es tener un entorno de staging donde probar actualizaciones antes de aplicarlas en producción, en vez de demorar los parches indefinidamente. Si tu hosting en donweb.com incluye staging o cpanel con snapshots, aprovechalo para este flujo.
Wordfence y plugins de seguridad similares pueden detectar intentos de explotación en sus reglas de firewall, pero no sustituyen el parcheo. Son una capa adicional, no el reemplazo.
Errores comunes al manejar este tipo de vulnerabilidades
Error 1: «El sitio es pequeño, nadie lo va a atacar.» Los ataques a endpoints vulnerables son automatizados. Bots escanean rangos de IP buscando versiones vulnerables de plugins conocidos. El tamaño del sitio no importa.
Esto está relacionado con lo que analizamos en CVE-2026-6675, donde cubrimos el tema en detalle.
Para más detalles, revisá nuestro artículo sobre CVE-2026-6675.
Si querés saber más de esto, tenemos un artículo dedicado al CVE-2026-6675.
Error 2: Desactivar el plugin y asumir que el problema está resuelto. La desactivación cierra la vulnerabilidad activa, pero si el endpoint fue explotado antes de desactivar, el daño reputacional en listas negras puede persistir. Siempre auditá los logs del período de exposición. Más sobre esto en alertas de seguridad crítica recientes.
Error 3: Actualizar sin hacer backup previo. Poco frecuente que una actualización de plugin rompa el sitio, pero ocurre. Sin backup, un conflicto de compatibilidad con el tema o con otro plugin puede dejarte con el sitio caído sin opción de rollback rápido.
Preguntas Frecuentes
¿Qué es CVE-2026-6675 y cómo me afecta?
CVE-2026-6675 es una vulnerabilidad en el plugin Responsive Block Editor Addons para WordPress que permite a cualquier persona en internet enviar emails arbitrarios usando el servidor de correo de tu sitio. Afecta versiones hasta 2.2.0. Si tenés ese plugin instalado y activo en esa versión, tu servidor puede estar siendo usado como relay de spam sin que lo sepas.
¿Mi sitio WordPress está vulnerable al email relay?
Sí, si tenés instalado Responsive Block Editor Addons en versión 2.2.0 o anterior y el plugin está activo. Verificá la versión desde Plugins → Plugins instalados en tu admin. Si el número es menor a 2.2.1, el endpoint REST vulnerable está expuesto. Tema relacionado: fortalecer tu perímetro de defensa.
¿Cómo actualizo Responsive Blocks a una versión segura?
Desde el panel de WordPress, ir a Actualizaciones y aplicar la actualización disponible del plugin. La versión 2.2.1 incluye el parche que valida el campo de email y restringe el acceso al endpoint. Antes de actualizar, generá un backup completo del sitio.
¿Puede alguien enviar emails desde mi dominio sin permiso?
Con esta vulnerabilidad activa, sí. El endpoint REST del plugin acepta un parámetro de destinatario sin validación ni autenticación. Cualquier atacante puede enviar un POST request con la dirección que quiera y el servidor de correo de tu WordPress lo procesa como si fuera un envío legítimo de tu sitio.
¿Cuál es el riesgo si no parcheo esta vulnerabilidad?
El riesgo principal es que tu dominio termine en listas negras de spam, lo que impide que tus emails legítimos (facturas, notificaciones, recuperación de contraseña) lleguen a destino. A eso se suma el potencial de que tu servidor envíe phishing o malware a nombre de tu empresa. La puntuación CVSS 5.3 subestima el impacto reputacional real, que puede ser considerablemente mayor.
Conclusión
CVE-2026-6675 no es una vulnerabilidad crítica en términos de puntuación CVSS, pero el impacto operativo puede superar lo que ese número sugiere. Convertir tu servidor en un relay abierto es el tipo de problema que no duele hasta que llegás un lunes y descubrís que tus emails de facturación están yendo directo al spam de tus clientes.
La solución es concreta y disponible: actualizar a Responsive Block Editor Addons 2.2.1+. El parche ya existe. Lo que queda de tu lado es ejecutarlo, revisar si el sitio fue explotado durante la ventana de exposición, y verificar que el dominio no haya quedado listado en blocklists.
Si revisás esto y encontrás que sí hubo actividad sospechosa en los logs, documentalo y tomá las medidas de deslistación correspondientes. El daño es reversible, pero requiere acción.