WordPress acaba de pasar por una de esas semanas que ponen nervioso a cualquier administrador de sistemas. En apenas dos dias, 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 llego como parche de seguridad con 10 vulnerabilidades corregidas, la segunda como correccion urgente de un fallo introducido por ese mismo parche y la tercera porque parte de los arreglos iniciales no habian quedado completos.
No es algo habitual, y deja una leccion clara para cualquiera que mantenga un WordPress en produccion: en una actualizacion de seguridad conviene instalar rapido, pero tambien vigilar las horas siguientes por si el parche provoca efectos colaterales o necesita un retoque adicional. Es justo lo que ha pasado esta semana con WordPress 6.9.
El punto de partida fue WordPress 6.9.2, publicado el 10 de marzo de 2026 como una actualizacion de seguridad de WordPress. La documentacion oficial detalla que esta version corregia 10 vulnerabilidades: 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 autorizacion en query-attachments, un path traversal en PclZip, otro bypass relacionado con Notes y un fallo XXE en la libreria externa getID3. WordPress recomendo actualizar de inmediato y recordo que estas correcciones se trasladarian, cuando hiciera falta, a todas las ramas que aun reciben parches.
Hasta ahi, todo entraba dentro de lo previsible para un CMS tan extendido. El problema es que esa misma actualizacion rompio algunas instalaciones. Pocas horas despues, el equipo del proyecto lanzo WordPress 6.9.3 como un «fast follow» de la 6.9.2. La razon no fue una nueva vulnerabilidad, sino un fallo funcional que dejo el frontal de algunos sitios en blanco. Segun WordPress, el error afectaba a temas que cargaban rutas de plantillas mediante un mecanismo poco habitual de «stringable objects». El equipo admitio que no era una tecnica oficialmente soportada (el filtro template_include solo acepta cadenas), pero decidio corregirla igualmente porque estaba causando roturas reales.
La historia no termino ahi. El 11 de marzo de 2026, WordPress publico 6.9.4. Y esta vez el motivo volvio a ser de seguridad. El proyecto explico que, tras revisar el trabajo realizado en 6.9.2 y 6.9.3, el equipo de seguridad detecto que no todos los arreglos se habian aplicado por completo en las versiones previas. Por eso fue necesario sacar otra actualizacion con los cambios pendientes. La pagina oficial de lanzamientos resume bien la situacion: 6.9.2 resolvio 10 problemas de seguridad, 6.9.3 arreglo un fallo que afectaba a un numero limitado de sitios y 6.9.4 termino de aplicar correcciones que no habian quedado cerradas del todo.
La documentacion de 6.9.4 concreta ademas que esta version incluia correcciones adicionales para el path traversal en PclZip, el bypass de autorizacion en la funcion Notes y el problema XXE en getID3: tres cuestiones que ya figuraban en el boletin de 6.9.2 pero que, a la vista de la revision posterior, necesitaban ajustes extra. Tambien detalla que archivos se tocaron en esta ultima 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 concatenacion de versiones es incomoda, pero tambien bastante ilustrativa. Demuestra que el proyecto reacciono rapido: primero para tapar el agujero, despues para restaurar la compatibilidad de las webs rotas y al final para cerrar los flecos que quedaban abiertos. No es el escenario ideal, pero si una muestra de que el ciclo de correccion se mantuvo activo durante horas, sin esperar semanas a un mantenimiento posterior. Si quieres entender mejor como funciona este proceso, te recomendamos repasar nuestra guia sobre como actualizar WordPress de forma segura.
La respuesta practica es sencilla: hay que actualizar a WordPress 6.9.4 cuanto antes. La propia pagina de archivo de versiones deja claro que solo la version mas reciente de la rama 6.9 esta activamente mantenida y se considera segura. 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.
Tambien conviene revisar algo mas que el numero de version. Si una web mostro pantalla en blanco o un comportamiento extraño tras instalar 6.9.2, lo razonable es comprobar que el tema afectado vuelve a cargar bien con 6.9.3 o, mejor, con 6.9.4. Y si el sitio usa personalizaciones poco convencionales en la carga de plantillas, este episodio recuerda que los atajos fuera de la API soportada acaban pasando factura cuando llega una actualizacion critica. Antes de tocar nada, asegurate de tener una copia de seguridad reciente de WordPress y, si tu trafico es alto, aprovecha un entorno de staging.
A nivel tecnico hay otro detalle interesante. La misma secuencia de parches tambien ha afectado al ciclo de desarrollo de WordPress 7.0. El equipo publico una beta 4 adicional de la futura version 7.0 para asegurarse de que la rama en pruebas tambien incorporaba las correcciones de seguridad, sin dejar desprotegidos a quienes trabajan en entornos de test y validacion. Es una señal menor para el usuario final, pero importante a nivel de proyecto: la seguridad no se trato como algo aislado de la rama estable, sino como prioridad transversal en todas las ramas vivas. Si quieres saber por donde van los tiros del nuevo ciclo, mira nuestra cobertura de las novedades de WordPress 7.0.
Lo ocurrido con WordPress 6.9.2, 6.9.3 y 6.9.4 deja una conclusion que muchos administradores ya conocen, pero que conviene repasar: actualizar WordPress no es solo pulsar un boton, tambien es tener un procedimiento. Copias de seguridad, staging, vigilancia de errores tras el despliegue y una revision rapida de temas y plugins criticos siguen siendo igual de necesarios, incluso cuando la actualizacion 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 comoda es que, durante unas horas, algunos usuarios tuvieron que elegir entre cerrar vulnerabilidades, arreglar una web rota y volver a actualizar al dia siguiente para quedar realmente protegidos. Para un CMS que mueve una porcion enorme de la web, episodios asi recuerdan que la gestion del riesgo no termina al instalar un parche: empieza justo despues. Si tu instalacion sigue en ramas antiguas, este es buen momento para revisar tu calendario de mantenimiento y considerar si necesitas un plan de actualizaciones automaticas mejor afinado.
La ultima version segura y activamente mantenida de la rama 6.9 es WordPress 6.9.4, publicada el 11 de marzo de 2026. Es la unica que incluye todos los parches de seguridad aplicados de forma completa.
Porque 6.9.2 rompio el frontal de algunos sitios que usaban un sistema poco habitual de carga de plantillas mediante stringable objects. WordPress saco 6.9.3 como «fast follow» para devolver la compatibilidad a esos sitios, sin tocar la parte de seguridad.
El equipo de seguridad detecto que algunos arreglos de 6.9.2 (path traversal en PclZip, bypass en Notes y XXE en getID3) no se habian aplicado del todo. WordPress publico 6.9.4 para completar esas correcciones y dejar la rama 6.9 totalmente protegida.
No. WordPress indica que solo la version mas reciente de la rama 6.9 esta activamente soportada, asi que lo correcto es actualizar a 6.9.4 en cuanto puedas. Quedarse en 6.9.2 o 6.9.3 deja vulnerabilidades sin cerrar.
Si, pero de forma controlada. El equipo publico una beta 4 adicional de WordPress 7.0 para incorporar las mismas correcciones de seguridad en la rama de desarrollo, de modo que quienes prueban la nueva version no quedan expuestos a los fallos parcheados en 6.9.4.
