El 19 de agosto salió WordPress 7.1 «Mary Lou» con más de 1.500 mejoras en el changelog. Horas después, miles de sitios empezaron a devolver pantalla en blanco. Sin aviso previo en el dashboard. Sin posibilidad de entrar al panel para desactivar el plugin que lo provocaba. Yo lo vi en clientes que tenían auto-actualizaciones activadas y WP Rocket instalado: frontend caído, backend caído, soporte desbordado.
WP Rocket publicó su post-mortem el 26 de agosto y ahí está la historia completa. No fue un ataque. No fue mala configuración del hosting. Fue un cambio en cómo el Core genera los IDs de los callbacks de los hooks de WordPress, combinado con PHP 8 y tipado estricto. El resultado: un error fatal que tumbaba sitios enteros.
Según WP Rocket, cerca del 27% de sus usuarios corría la combinación en riesgo, pero alrededor del 10% se vio realmente afectado. Diez de cada cien. En un ecosistema de millones de instalaciones, eso no es un incidente menor: es una avalancha de tickets, horas de downtime y restauraciones desde backup que nadie había planificado para un martes cualquiera.
Lo que no cuadra del lanzamiento
DonWeb recoge en su análisis del error otro detalle incómodo: la versión se publicó antes de tiempo, empezó a descargarse sin el anuncio oficial en el escenario de WordCamp US, y la coordinación entre Core y el ecosistema de plugins fue, como mínimo, desastrosa. Weston Ruter, mantenedor del Core, confirmó el 21 de agosto que el cambio en los IDs de callback era un breaking change. Un breaking change en una actualización mayor que millones de sitios instalan sola.
El hotfix de WP Rocket (3.23.2.2) salió la mañana del 20 de agosto, a las 10:11 CEST. WordPress 7.1 se publicó oficialmente a las 02:18 CEST del mismo día. Ocho horas en las que cualquier sitio con auto-updates activadas podía actualizarse y quedarse muerto antes de que existiera parche. Piénsalo: tu cliente desayuna, abre la web de su negocio, y no carga. Tú no puedes entrar al admin. El hosting te dice que restaures backup. Y la causa es una actualización automática del CMS que nadie autorizó manualmente ese día.
WordPress ya busca release managers para la 7.1.1, según el llamamiento oficial, con fecha estimada entre el 1 y el 24 de septiembre. Dependiendo de la gravedad de los bugs reportados. Traducción: si tu sitio se cayó, espera hasta mediados de mes para que el Core parchee lo que rompió el Core.
El problema de fondo no es WP Rocket
El bug concreto afectó sobre todo al módulo de Cloudflare de WP Rocket y a plugins con tipado estricto como Elementor Pro. WP Rocket lo solucionó poniendo una guarda: si el plugin de Cloudflare no está activo, no ejecutes esa ruta. Simple. Efectivo. Pero revelador: el plugin estaba cargando código de Cloudflare en sitios que ni siquiera usaban Cloudflare. Eso es deuda técnica acumulada, sí. Pero la chispa la provocó WordPress cambiando el tipo de dato de un identificador interno sin avisar con suficiente antelación al ecosistema.
En foros y blogs en inglés lo que más se repite no es «qué mal WP Rocket», sino «otra vez auto-updates como ruleta rusa». Y tienen razón. WordPress empuja las actualizaciones automáticas como mecanismo de seguridad — parchear XSS y vulnerabilidades sin intervención del usuario. Pero cuando el propio Core introduce un breaking change que tumba el sitio, ese argumento se invierte: la auto-actualización se convierte en el vector del problema.
Yo llevo años recomendando staging antes de actualizar major releases. Siempre. Pero sé que la mitad de las pymes que mantengo no tienen staging, no tienen monitorización, y sí tienen auto-updates activadas porque «así va solo». Este incidente demuestra que «va solo» puede significar «se cae solo a las tres de la madrugada un martes».
Qué haría yo a partir de ahora
Primero: desactiva auto-updates para versiones major (7.x, 8.x) en sitios de producción sin entorno de pruebas. Los parches de seguridad menores (7.1.1, 7.1.2) sí pueden ir automáticos una vez verificado que la .0 no ha roto nada. Segundo: monitorización externa que te avise en minutos, no cuando el cliente llama enfadado. Tercero: antes de cada major, revisa los plugins críticos — caché, page builders, SEO — y mira si han publicado notas de compatibilidad.
Cuarto, y esto es opinión mía: el Core debería separar claramente «actualizaciones de seguridad» de «actualizaciones con breaking changes potenciales». Que el usuario elija. Que no sea opt-out sino opt-in para majors. Lo sé, suena conservador. Pero prefiero un sitio con un parche de seguridad pendiente 48 horas — que puedo aplicar en staging — a un sitio muerto 8 horas con zero ventas.
Mientras tanto, si tu sitio sigue en 7.0.x y tienes WP Rocket, Elementor Pro o plugins con integraciones profundas en hooks del Core, no actualices a 7.1 hasta confirmar compatibilidad o hasta que salga la 7.1.1 con el fix oficial. No es miedo: es aprendizaje de lo que acaba de pasarle a miles de sitios reales.
Si mañana tu proveedor de hosting te ofreciera activar auto-updates de majors a cambio de un 15% de descuento en la cuota anual, pero sin garantía de rollback automático si el Core rompe compatibilidad, lo aceptarías?