WordPress publicó el 28 de octubre de 2026 la versión 7.1.4, una actualización de seguridad que corrige, entre otros problemas, una vulnerabilidad de ejecución remota de código (RCE) en el core. Afecta a las versiones 4.7 a 7.1.3.
La falla ya se está atacando: Wordfence informó 62.969 intentos de ataque bloqueados en 24 horas, según The Hacker News (30 de octubre).
A diferencia de la mayoría de los incidentes de WordPress, que se originan en plugins o temas de terceros, esta falla está en el core (el código base que comparten todas las instalaciones). Alcanza a cualquier sitio en una versión afectada, sin importar qué plugins tenga.
Los sitios más expuestos suelen ser los que nadie administra de forma activa: micrositios de campañas, sitios institucionales heredados o instancias de prueba que quedaron publicadas.
Qué corrige WordPress 7.1.4
El anuncio oficial lista 13 correcciones de seguridad. Además del RCE, incluye varios XSS almacenados (código JavaScript que un usuario con permisos de edición deja guardado en el sitio y que se ejecuta en el navegador de quien lo abre) en bloques, la Interactivity API y el Customizer.
El análisis de Patchstack cuenta 22 vulnerabilidades agrupadas en 17 avisos. Según esa misma fuente, solo dos se pueden explotar sin cuenta en el sitio:
- El RCE durante la actualización del core, reportado por Umut Bayram.
- La exposición de cambios no publicados del Customizer, reportada por Antonio Lorensius Silaban. Desde 7.1.4 se requiere el permiso
customizepara verlos.
El resto requiere una cuenta con rol de Colaborador o superior. Entre quienes reportaron vulnerabilidades figura Anthropic, con dos problemas en pantallas de administración.
Cómo funciona el RCE
Una vulnerabilidad de ejecución remota de código permite a un atacante correr sus propios comandos en el servidor del sitio. Con eso puede modificar el contenido, acceder a la base de datos o instalar software malicioso.
Según el análisis técnico de Wordfence citado por The Hacker News, cuando WordPress aplica una actualización completa del core desempaqueta los archivos nuevos en un directorio con nombre predecible dentro de wp-content/upgrade, accesible desde la web.
Esa copia incluye el instalador de WordPress. Un atacante sin autenticación que lo solicita en el momento justo puede llegar a ejecutar código PHP en el servidor.
Se trata de una condición de carrera: el ataque solo funciona dentro de la ventana de la actualización, que en pruebas de laboratorio dura segundos. Por eso tiene una puntuación CVSS (la escala de 0 a 10 con la que se compara la gravedad de las vulnerabilidades) de 8,1, alta y, según The Hacker News, no tiene un CVE asignado.
Qué se observa en los ataques
Para acertarle a la ventana, los atacantes consultan los sitios de forma repetida. Wordfence observó solicitudes a rutas como setup-config.php, con muchas variantes de nombres de directorio y de versión.
Dos de las fuentes más activas consultaron de forma continua pequeños grupos de sitios durante unas 14,5 horas.
Es la segunda falla grave del core de WordPress atacada este año. En julio, la cadena conocida como wp2shell (CVE-2026-63030 y CVE-2026-60137) recibió los primeros intentos de explotación unos 90 minutos después de publicada la versión 7.0.2, según Patchstack.
Qué tiene que hacer un equipo de IT
- Inventariar los sitios WordPress de la organización, incluidos los de marketing, los micrositios y los que administra una agencia externa.
- Actualizar a 7.1.4 o a la versión corregida de cada rama: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 y así hasta 4.7.39 (detalle en Patchstack). Las versiones 4.6 y anteriores no reciben el parche.
- Verificar las actualizaciones automáticas en segundo plano: el anuncio oficial indica que los sitios que las tienen activas se actualizan solos.
- Bloquear el acceso web a
wp-content/upgrade/en el servidor web y confirmar que no se puede listar. Patchstack advierte que un firewall implementado en PHP no frena este ataque, porque la copia desempaquetada corre sin losmu-pluginsdel sitio. - Buscar indicios de compromiso: solicitudes sospechosas a archivos PHP dentro de
wp-content/upgradeen los logs, y cuentas de administrador, plugins o archivos PHP desconocidos. - Revisar quién tiene rol de Colaborador o superior, ya que la mayoría de las demás vulnerabilidades lo requieren.
¿Cuánto tarda su organización en aplicar un parche de WordPress?
¿Tienen las actualizaciones automáticas activas o dependen de una ventana de mantenimiento? Te leemos en los comentarios.


