WordPress 7.1 salió hace tres semanas. Ya necesita un parche de emergencia

WordPress 7.1, con nombre en clave «Mary Lou», se publicó el 19 de agosto de 2026. Trajo cosas de verdad útiles: un bloque de pestañas, un bloque de tabla de contenidos que se construye solo a partir de los encabezados, estilos por estado (hover, focus) en Global Styles, y redimensionado de imágenes en el navegador antes de subirlas, en vez de en el servidor.

Tres semanas después, el 17 de septiembre sale la 7.1.1: un parche de mantenimiento, solo correcciones, sin funciones nuevas. Y no es un parche cualquiera.

El fallo que encabeza la lista es un bug en multisite que borra contenido en silencio al eliminar un usuario — sin aviso, sin confirmación extra, sin rastro claro de qué se fue. Junto a él, un error fatal provocado porque las claves de WP_Hook::$callbacks cambiaron de texto a número durante el ciclo de la 7.1, más regresiones en las miniaturas de PNG indexados, tooltips que no se pintan bien y varios fallos de interfaz en admin y móvil.

A eso se suman unos 20 cambios de Gutenberg sobre editor y subida de medios. Es, en resumen, una lista larga de cosas que la propia actualización oficial rompió hace tres semanas y que ahora hay que volver a tocar para arreglar.

El 22 de septiembre salió la 7.1.2, y esta vez no era mantenimiento. Corrige el CVE-2026-87902, un fallo crítico (CVSS 9,2) que no necesita iniciar sesión para explotarse: un visitante anónimo puede hacer que la web cargue un fichero PHP de fuera de la carpeta del tema y, si se dan ciertas condiciones, acabar ejecutando código en el servidor.

Una de esas condiciones es que el tema activo, padre o hijo, tenga una carpeta de primer nivel cuyo nombre empiece por page-, como el page-templates que usan muchos temas. Y lo peor es la fecha: el fallo está en todas las versiones desde la 4.7, de finales de 2016. Por eso hay parches para la 7.0 y para versiones anteriores hasta la 6.2, según las notas de Pantheon.

Son tres versiones de la 7.1 en cinco semanas. Y la última no arregla algo que hubiera roto la 7.1: arregla algo que llevaba casi diez años en el núcleo.

Ya habíamos hablado de que cada actualización de plugin es una ruleta rusa semanal: actúas o te arriesgas a que algo se rompa, no actúas y te quedas expuesto. La diferencia esta vez es que el origen del riesgo no es un plugin de tercero con recursos limitados — es el propio núcleo de WordPress, mantenido por el equipo más grande y mejor financiado de todo el ecosistema.

Si ni siquiera esa actualización llega limpia —y hace falta un parche de emergencia a las tres semanas para un bug que borra contenido—, el argumento de «actualiza siempre, es lo más seguro» se topa con la realidad: a veces la actualización es el incidente.

La Beta 1 de WordPress 7.2 está prevista para el 20–22 de octubre, apenas un mes después de la 7.1.1. El ciclo no se detiene para que nadie respire: mientras se corrige lo que rompió la versión anterior, ya está en marcha la siguiente. Entre las novedades que se van confirmando para más adelante, el bloque Clásico deja de aparecer por defecto en el insertor desde la 7.1, y la coedición en vivo sigue en pruebas sin fecha de lanzamiento firme — de momento la colaboración va por un sistema de notas asíncronas.

Nada de esto es un problema si no hay un núcleo que actualizar cada pocas semanas. En Forja no hay una versión de WordPress corriendo en el servidor a la que aplicarle el próximo parche de emergencia: el contenido se compila una vez, se publica, y lo que ve el visitante no depende de ningún proceso vivo que un ciclo de lanzamientos pueda romper entre medias.

Si sigues en WordPress, la recomendación es simple: comprueba que estás en la 7.1.2 o posterior (o en el parche de tu rama, si sigues en una versión anterior). No lo dejes para «cuando tengas un rato». Un fallo sin autenticación que lleva diez años en el núcleo es exactamente el tipo de cosa que nadie presupuesta como coste de mantenimiento hasta que ya ha pasado.