En pocas palabras: CVE-2026-114570 es un XSS almacenado en Quick Edit del core de WordPress (CWE-79, CVSS 4.9) que afecta versiones desde 4.7.0 hasta 7.0.2. Un Colaborador autenticado puede inyectar código vía el nombre de usuario. Ya está corregido en WordPress 7.0.3, liberado el 6 de agosto de 2026.

El 22 de octubre de 2026 se publicó el registro de CVE-2026-114570, una falla XSS almacenado en el Quick Edit del core de WordPress que afecta todas las versiones hasta la 7.0.2. El parche ya existe: WordPress 7.0.3, liberado en agosto.

CVE-2026-114570 es una vulnerabilidad de cross-site scripting (XSS) almacenado, catalogada bajo CWE-79, que afecta al núcleo de WordPress en todas las versiones publicadas entre la 4.7.0 y la 7.0.2. El fallo está en la función Quick Edit, donde el escape insuficiente del nombre de visualización de usuario permite que un Colaborador autenticado inyecte código que se ejecuta cuando un editor o administrador abre esa pantalla.

En 30 segundos

  • CVE-2026-114570 tiene CVSS 4.9 (severidad media) y CWE-79.
  • Afecta a WordPress Core desde la versión 4.7.0 hasta la 7.0.2, prácticamente todas las instalaciones activas.
  • El parche ya existe desde el 6 de agosto de 2026 con WordPress 7.0.3, que corrigió esta falla junto a once vulnerabilidades más.
  • EPSS estima apenas 0.18% de probabilidad de explotación en los próximos 30 días, percentil 7.2.
  • Requiere un atacante autenticado con rol de Colaborador o superior; no es explotable de forma anónima.

¿Qué es CVE-2026-114570 y qué versiones de WordPress afecta?

Es una falla de escape insuficiente en el core de WordPress que permite inyectar scripts a través de Quick Edit, registrada como CVE-2026-114570 el 22 de octubre de 2026 con CVSS 4.9. El rango afectado es amplio.

Según el advisory, cada rama de mantenimiento tiene su propio tope vulnerable: desde 4.7.0 hasta 4.7.33, de 5.0.0 hasta 5.0.25, de 6.9.0 hasta 6.9.5, y así hasta la última rama activa, la 7.0.0 a 7.0.2. Básicamente, si tu instalación venía de antes de agosto de 2026 y no actualizaste, estás adentro del rango.

El vector técnico es AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N. Eso significa ataque remoto (AV:N), complejidad alta (AC:H), privilegios bajos requeridos (PR:L) y alcance cambiado (S:C), lo que indica que el componente vulnerable (el perfil del colaborador) no es el mismo que el componente impactado (la sesión del admin que abre Quick Edit).

¿Cómo funciona el ataque y quién puede explotarlo?

El ataque requiere un usuario autenticado con rol de Colaborador o superior, que modifica su nombre de visualización con una carga maliciosa; cuando un editor o administrador abre la pantalla de Quick Edit para revisar ese contenido, el navegador ejecuta el script sin pedir ningún clic extra.

Ejemplo hipotético (ilustrativo, no es un caso real reportado): imaginemos un sitio con alta de colaboradores abierta para que cualquiera mande notas. Alguien se registra, edita su perfil, le pone como nombre de usuario algo que en realidad es una etiqueta <script> camuflada, y espera. Tarde o temprano un editor entra a revisar ese post desde Quick Edit, y ahí el código corre con los privilegios de esa sesión.

¿Necesita el atacante ser admin? No. Alcanza con Colaborador, el rol más bajo que puede escribir borradores en WordPress.

¿Por qué el riesgo es mayor en sitios con muchos usuarios registrados?

Porque el propio advisory lo deja claro: «this issue only affects sites with a large number of users», según el reporte técnico recogido en Strix. Cuantos más colaboradores tenga un sitio, más probable es que uno sea malicioso y que un admin termine abriendo su perfil en algún momento.

Un sitio chico con dos o tres autores de confianza prácticamente no corre riesgo real acá. Un medio digital con cientos de colaboradores externos, en cambio, es un blanco mucho más jugoso: alguien se cuela entre el ruido de usuarios y nadie lo nota hasta que ya fue.

Cómo priorizar la actualización según el tipo de sitio

No todos los sitios corren el mismo riesgo con esta falla. Cruzando el CVSS bajo con el dato de que «solo afecta a sitios con muchos usuarios» y que requiere rol de Colaborador, se puede armar un criterio simple para decidir si la actualización es urgente o puede esperar al próximo mantenimiento:

Perfil del sitio Registro de colaboradores Prioridad de actualización
Blog personal, 1 a 5 autores de confianza Cerrado o por invitación Baja: actualizá en el próximo ciclo de mantenimiento
Sitio corporativo con equipo interno fijo Cerrado Media: no hay apuro, pero no lo dejes pasar más de un mes
Medio o blog colaborativo con decenas o cientos de colaboradores externos Abierto o con alta semi-automática Alta: actualizá ahora y revisá la moderación de altas
Red multisitio con registro público habilitado Abierto Alta: sumá revisión de las otras fallas de 7.0.3 (SSRF y escalada multisitio)
cve-2026-114570 wordpress diagrama explicativo

La lógica detrás de esta tabla es simple: la severidad técnica (4.9) es baja, pero la condición que activa el riesgo real -muchos usuarios con capacidad de escribir- depende pura y exclusivamente de cómo administrás tu sitio, no de la versión de WordPress en sí.

¿Ya existe un parche? WordPress 7.0.3 y el backport a versiones antiguas

Sí. El parche salió el 6 de agosto de 2026 con WordPress 7.0.3, que corrigió doce vulnerabilidades del core, entre ellas esta de Quick Edit, y retroportó el fix a todas las ramas de mantenimiento hasta la 4.7. El cambio concreto quedó registrado en el changeset 63061 del repositorio oficial.

El registro del CVE del 22 de octubre no es un parche nuevo. Es la divulgación pública y la asignación formal del CVE para una falla que ya estaba resuelta hace meses, algo bastante normal en el ciclo de vida de este tipo de reportes.

Vale la pena mirar el paquete completo de 7.0.3, porque la de Quick Edit no fue la más grave. Según Search Engine Journal, la misma actualización corrigió un XSS reflejado pre-autenticación en la pantalla de login, calificado 8.9/10 (alta severidad), con potencial de escalar a ejecución remota de código mediante ingeniería social, además de un SSRF que permitía peticiones a rangos de IP link-local y una escalada de privilegios en redes multisitio con registro abierto.

Oliver Sild, de Patchstack, dijo a Search Engine Journal: «We’re tracking whether it’s getting exploited, but looks like the social engineering bit on the XSS that could lead to RCE is most likely not going to get much attention from the hackers». Dicho en criollo: lo están vigilando, pero no esperan explotación masiva porque requiere convencer a una víctima de hacer clic en algo.

¿Cómo actualizar WordPress para corregir esta vulnerabilidad?

Actualizá a 7.0.3 o superior desde el panel de administración, ahora mismo si todavía no lo hiciste. El proceso es rápido y WordPress lo aplica por partes automáticamente en la mayoría de los casos.

  • Revisá tu versión actual. Entrá a Escritorio > Actualizaciones y confirmá si estás en 7.0.3 o una versión de mantenimiento posterior a tu rama.
  • Activá las actualizaciones automáticas de seguridad. WordPress las aplica solo si no las desactivaste manualmente en el wp-config.php o con un plugin.
  • Si usás una rama LTS vieja (como 6.5 o 6.6), confirmá el backport. El fix llegó hasta la 4.7, pero conviene chequear el número exacto de build.
  • Revisá los roles de usuario. Si tenés alta de colaboradores abierta sin moderación, limitala o agregá aprobación manual.
  • Considerá hosting administrado que facilite el mantenimiento del core. En planes de hosting gestionado como los de donweb.com, contar con soporte y gestión del proveedor puede ayudar a mantener el sitio al día y reducir la ventana de exposición.

Errores comunes al manejar este tipo de vulnerabilidades

  • Pensar que un CVSS medio no merece atención. 4.9 no es crítico, pero afecta a prácticamente todas las instalaciones activas de WordPress. La masividad compensa la severidad baja.
  • Dejar el registro de colaboradores abierto sin moderación. Es la puerta de entrada exacta que necesita este ataque. Cerrala o agregá revisión manual de altas.
  • Confundir «parche disponible» con «ya estoy protegido». Tener 7.0.3 descargado en el servidor no sirve si no se aplicó. Confirmá la versión activa, no la descargada.
  • Ignorar el backport en ramas viejas. Si corrés WordPress 5.x por compatibilidad con un plugin legacy, el fix también te llegó. No hace falta saltar a la rama 7 para estar protegido.

Preguntas Frecuentes

¿Qué versión de WordPress soluciona CVE-2026-114570?

WordPress 7.0.3, publicada el 6 de agosto de 2026, corrige esta falla. El fix también se retroportó a todas las ramas de mantenimiento anteriores, hasta la 4.7.

¿Necesito ser administrador para explotar esta falla?

No. Alcanza con tener rol de Colaborador, el nivel de permisos más bajo con capacidad de escribir contenido en WordPress. El atacante inyecta el script en su propio nombre de usuario.

¿Mi sitio está en riesgo si tiene pocos usuarios?

El riesgo es bajo. El propio advisory aclara que el problema afecta principalmente a sitios con una gran cantidad de usuarios registrados, donde es más probable que un colaborador malicioso pase desapercibido. Usá la tabla de priorización de este artículo para ubicar tu caso puntual.

¿Cómo sé si mi WordPress está actualizado y seguro?

Entrá a Escritorio > Actualizaciones en tu panel y confirmá que la versión instalada sea 7.0.3 o superior, o la última de mantenimiento de tu rama. Si está desactualizada, actualizá de inmediato.

¿Qué significa el 0.18% de EPSS en esta vulnerabilidad?

EPSS estima la probabilidad de explotación activa en los próximos 30 días. Un 0.18%, ubicado en el percentil 7.2, indica que la chance de un ataque masivo real es baja comparada con otras CVE del mismo período.

Conclusión

CVE-2026-114570 confirma algo que viene pasando con el core de WordPress desde hace un par de años: cada vez aparecen más fallas documentadas, en parte gracias a herramientas de auditoría asistidas por IA que escanean el código con más profundidad que antes. El riesgo real acá es bajo para la mayoría de los sitios chicos, pero si administrás un medio o una plataforma con registro abierto de colaboradores, no da para ignorarlo.

Lo accionable es simple: confirmá que estés en 7.0.3 o superior, y si no, actualizá ya. Usá la tabla de priorización según tu tipo de sitio para decidir si es urgente o puede esperar al próximo mantenimiento. No hace falta esperar ningún anuncio adicional, el parche existe desde agosto. Lo único nuevo del 22 de octubre es el número de CVE y la documentación pública del caso.

Fuentes

Categorizado en: