Jueves, 29 de octubre de 2026

Lo más relevante del hosting en el mundo, en español · ehost.ec →

WordPress 7.1.4 corrige 22 fallos y cierra una ventana de RCE sin cuenta en actualizaciones

WordPress publicó el 28 de octubre de 2026 la versión 7.1.4 con correcciones para 22 vulnerabilidades en 17 avisos; la actualización incluye un parche que evita una ejecución remota de código (RCE) durante el proceso de actualización sin necesidad de cuenta.

Por Equipo ehost3 min de lecturaFuente: Patchstack Blog
WordPress 7.1.4 corrige 22 fallos y cierra una ventana de RCE sin cuenta en actualizaciones
Imagen ilustrativa generada con inteligencia artificial.

WordPress 7.1.4, publicado el 28 de octubre de 2026, aborda 22 vulnerabilidades agrupadas en 17 avisos de seguridad. La mayoría requieren que el atacante tenga una cuenta de usuario con privilegios, normalmente al menos el rol Contributor, pero una excepción crítica afectaba a instalaciones durante el proceso de actualización y permitía ejecución remota de código sin autenticación.

Qué cambia: seguridad del proceso de actualización y del API de Interactivity

La corrección más relevante actúa sobre cómo WordPress maneja los ficheros temporales al instalar o actualizar paquetes. Antes de 7.1.4, las copias extraídas se colocaban en wp-content/upgrade/ con un nombre predecible derivado del paquete y la rutina de limpieza podía eliminar el index.php que impide la lista de directorios. Durante los segundos que dura la extracción, una copia completa del instalador quedaba accesible desde una ruta adivinable y podía ejecutarse setup-config.php contra una base de datos controlada por un atacante.

Para cerrar esta ventana, 7.1.4 añade 16 caracteres aleatorios al nombre de la carpeta de extracción, recrea el index.php y evita eliminarlo. Además, se modificó el código de actualización para excluir wp-config.php de los archivos copiados fuera del directorio de trabajo. Estas medidas reducen drásticamente la posibilidad de alcanzar y ejecutar el instalador temporal sin credenciales.

Interactivity API y filtros KSES: qué se ha corregido

Una parte importante de los avisos afectan a la Interactivity API y a KSES, el filtrado HTML que decide qué etiquetas y atributos puede guardar un usuario sin la capacidad unfiltered_html. KSES permitía cualquier atributo data-* con cualquier valor, y las directivas de Interactivity se implementan como data-*; así, un usuario Contributor podía inyectar directivas en contenido y lograr que el runtime del cliente las ejecutara cuando un visitante cargaba la página.

Los parches de 7.1.4 actúan en varios puntos: KSES ahora elimina bindings que puedan cambiar un valor previamente validados; el procesador PHP de directivas restringe enlaces sobre elementos object; y el runtime cliente rechaza objetivos inseguros (por ejemplo, javascript:). Además se corrigió un parser CSS que podía provocar un bloqueo del navegador del visitante por un bucle que reaplicaba el procesamiento.

Otras correcciones destacadas

  • Comprobación de que el estado de Interactivity provenga realmente de un elemento <script> específico (evita que otro elemento con el mismo id suplante los datos).
  • Se evitó que la vista previa del Personalizador adopte un changeset sin verificar capacidades, ahora exige la capacidad de customizar.
  • Se repararon varios bloques (Categories, Image, Playlist, Comments Pagination, Post Navigation Link) que reinterpretaban contenido ya filtrado o imprimían atributos sin el escape adecuado; ahora usan la API de HTML y escapan etiquetas cuando procede.
  • Uniformidad en el parseo de delimitadores de bloques para evitar discrepancias entre el parser PHP y el editor JavaScript.
  • La REST controller de comentarios ya exige permiso de edición del post para modificar notas asociadas, corrigiendo un requisito de capacidades demasiado laxo.

Impacto y acciones recomendadas para administradores

La actualización es relevante para cualquier sitio WordPress. Los parches están disponibles también como backports para ramas soportadas hasta 4.7.39, según el comunicado oficial. Las páginas con actualizaciones en segundo plano recibirán el parche automáticamente si están configuradas para ello.

Acciones prácticas que deben realizar administradores y propietarios de sitios:

  • Actualizar a 7.1.4 lo antes posible o aplicar el backport correspondiente si se usa una rama anterior soportada.
  • Comprobar que wp-content/upgrade/ no sea accesible públicamente y que el directorio no permita listado (configurar el servidor para denegar acceso a esa ruta y dejar un index.php que no muestre contenido).
  • Revisar qué usuarios tienen rol Contributor o superior y ajustar privilegios: muchas de las vulnerabilidades requerían al menos ese nivel de cuenta.
  • Si se usan personalizaciones de roles o plugins que alteran capacidades, verificar que no separen permisos que ahora se exigen conjuntamente (por ejemplo, moderate_comments vs edit_others_posts).

Si no puede actualizar de inmediato, al menos implemente la mitigación de bloqueo de acceso a wp-content/upgrade/ en la configuración del servidor web; esto cierra la única falla explotable sin cuenta.

Lee también:

Fuente: Patchstack Blog

Compartir