WordPress ha vivido una de esas secuencias de actualizaciones que inquietan a cualquier administrador de sistemas, desarrollador o responsable de una web en producción. En apenas dos días, el proyecto ha publicado tres versiones consecutivas de la rama 6.9: la 6.9.2, la 6.9.3 y la 6.9.4. La primera llegó como parche de seguridad, la segunda como corrección urgente de un fallo introducido por ese parche y la tercera porque parte de las vulnerabilidades iniciales no habían quedado completamente corregidas.
No es una situación habitual, pero sí deja una enseñanza clara para el ecosistema WordPress: en una actualización de seguridad, instalar rápido sigue siendo importante, aunque también conviene vigilar durante las horas posteriores si el parche genera efectos colaterales o necesita un ajuste adicional. Y eso es exactamente lo que ha ocurrido esta semana con WordPress 6.9.
El punto de partida fue WordPress 6.9.2, publicado el 10 de marzo de 2026 como una actualización de seguridad. La documentación oficial detalla que esta versión corregía 10 vulnerabilidades, entre ellas un Blind SSRF, una debilidad PoP-chain en la HTML API y Block Registry, un regex DoS, varios problemas de XSS almacenado, un bypass de autorización en query-attachments, un problema de path traversal en PclZip, otro bypass de autorización relacionado con Notes y un fallo XXE en la librería externa getID3. WordPress recomendó actualizar de inmediato y recordó que estas correcciones se trasladarían, cuando fuera necesario, a todas las ramas aún elegibles para recibir parches de seguridad.
Hasta ahí, todo entraba dentro de lo esperado para un CMS tan extendido. El problema es que esa misma actualización rompió algunas instalaciones. Pocas horas después, el equipo del proyecto lanzó WordPress 6.9.3 como un “fast follow” de la 6.9.2. La razón no fue una nueva vulnerabilidad, sino un fallo funcional que dejó el frontal de algunos sitios en blanco. Según WordPress, el error afectaba a ciertos temas que cargaban rutas de plantillas mediante un mecanismo poco habitual de “stringable objects”. El equipo admitió que no era una técnica oficialmente soportada —el filtro template_include solo acepta una cadena—, pero decidió corregirla igualmente porque estaba causando roturas reales en algunas webs.
La historia no acabó ahí. El 11 de marzo de 2026, WordPress publicó 6.9.4. Y esta vez el motivo volvió a ser de seguridad. El proyecto explicó que, tras revisar el trabajo realizado en 6.9.2 y 6.9.3, el equipo de seguridad detectó que no todos los arreglos de seguridad se habían aplicado completamente en las versiones previas. Por eso fue necesario sacar otra actualización con los cambios pendientes. La propia página de lanzamientos de WordPress resume la situación de forma bastante clara: 6.9.2 resolvió 10 problemas de seguridad, 6.9.3 arregló un fallo que afectaba a un número limitado de sitios y 6.9.4 terminó de aplicar correcciones de seguridad que no habían quedado cerradas del todo.
La documentación de 6.9.4 concreta además que esta versión incluía correcciones adicionales para un path traversal en PclZip, un bypass de autorización en la función Notes y el problema XXE en getID3, tres cuestiones que ya figuraban en el boletín de 6.9.2 pero que, a la vista de la revisión posterior, necesitaban ajustes extra. También detalla qué archivos se tocaron en esta última ronda: wp-admin/includes/file.php, wp-includes/ID3/getid3.lib.php y wp-includes/rest-api/endpoints/class-wp-rest-comments-controller.php.
Para los administradores de WordPress, esta concatenación de versiones es incómoda, pero también bastante ilustrativa. Demuestra que el proyecto reaccionó deprisa, primero para tapar el agujero de seguridad, después para restaurar la compatibilidad de algunas webs rotas y finalmente para cerrar por completo los flecos que habían quedado abiertos. No es el escenario ideal, pero sí una muestra de que el ciclo de corrección se mantuvo activo durante horas, sin esperar semanas a un mantenimiento posterior.
La respuesta práctica es bastante sencilla: hay que actualizar a WordPress 6.9.4 cuanto antes. La propia página de archivo de versiones deja claro que solo la versión más reciente de la rama 6.9 se considera segura y activamente mantenida. Eso significa que quedarse en 6.9.2 o 6.9.3 no tiene sentido a estas alturas, aunque en su momento se instalaran como medida de urgencia.
También conviene revisar algo más que el número de versión. Si una web mostró una pantalla en blanco o un comportamiento extraño tras la instalación de 6.9.2, lo razonable es comprobar que el tema afectado vuelve a cargar correctamente con 6.9.3 o, mejor aún, con 6.9.4. Y si el sitio usa personalizaciones poco convencionales en la carga de plantillas, este episodio es un buen recordatorio de que los atajos fuera de la API soportada pueden acabar pasando factura cuando llega una actualización crítica.
A nivel técnico, hay otro detalle interesante. La misma secuencia de parches también ha afectado al ciclo de desarrollo de WordPress 7.0. El equipo publicó una beta 4 adicional de la futura versión 7.0 para asegurarse de que la rama en pruebas también incorporaba las correcciones de seguridad, sin dejar desprotegidos a quienes están trabajando con entornos de test y validación. Es una señal menor para el usuario final, pero importante para el ecosistema: la seguridad no se ha tratado como algo aislado de la rama estable, sino como una prioridad transversal en todas las ramas vivas.
Lo ocurrido con WordPress 6.9.2, 6.9.3 y 6.9.4 deja una conclusión que muchos administradores ya conocen, pero que a veces se olvida: actualizar WordPress no es solo pulsar un botón, también es tener un procedimiento. Copias de seguridad, staging, vigilancia de errores tras el despliegue y una revisión rápida de temas y plugins críticos siguen siendo igual de necesarios, incluso cuando la actualización llega etiquetada como “de seguridad” y pide instalarse cuanto antes.
La parte positiva es que el proyecto ha reaccionado con rapidez y transparencia. La parte menos cómoda es que, durante unas horas, algunos usuarios tuvieron que elegir entre cerrar vulnerabilidades, arreglar una web rota y volver a actualizar al día siguiente para quedar realmente protegidos. Para un CMS que mueve una porción enorme de la web, estos episodios recuerdan que la gestión del riesgo no termina al instalar un parche: empieza justo después.
La última versión segura y activamente mantenida de la rama 6.9 es WordPress 6.9.4, publicada el 11 de marzo de 2026.
Porque la actualización de seguridad 6.9.2 rompió el frontal de algunos sitios que usaban un sistema poco habitual de carga de plantillas mediante stringable objects, y WordPress lanzó 6.9.3 para corregir ese problema.
WordPress detectó que no todos los fixes de seguridad de 6.9.2 se habían aplicado completamente, así que publicó 6.9.4 para completar esas correcciones pendientes.
No es lo recomendable. WordPress indica que solo la versión más reciente de la rama 6.9 está activamente soportada, por lo que lo correcto es actualizar a 6.9.4.
