El CMS que sostiene la mitad de la web recibió dos releases críticos de core con cinco días de diferencia en septiembre. La falla: un path traversal no autenticado en la resolución de page templates, catalogado como GHSA-7hp8-65ch-5whp, corregido en los releases 6.9.9 y 7.1.2.
Sin login, sin cuenta, sin interacción: un atacante remoto envía secuencias de traversal con doble codificación y alcanza archivos fuera de la ruta prevista, con exposición e inclusión local de PHP que pueden escalar a ejecución condicional de código.
El mes en que el core se volvió blanco
La falla de septiembre no vino sola: en julio, el core recibió el CVE-2026-63030, el "wp2shell", un RCE crítico no autenticado. Dos releases críticos de core en pocos meses cuentan la historia de 2026: WordPress volvió al tope de la fila de la investigación ofensiva, y quien opera el CMS debe tratarlo como un sistema que recibe parche continuo, no como una instalación que se olvida.
La crisis de seguridad de WordPress ya estaba documentada aquí: la cadena de plugins y temas con código opaco es el problema estructural. La de septiembre agrega el capítulo core: cuando el propio núcleo exige dos parches de emergencia en semanas, el inventario de versiones deja de ser buena práctica y se vuelve supervivencia.
Por qué "mi sitio es pequeño" no es una defensa
La falla es explotable sin autenticación: el atacante no necesita cuenta, necesita dirección. Los scanners automatizados recorren toda la web detrás de versiones vulnerables, sin mirar el tamaño de la empresa.
En la práctica, los sitios pequeños son los más expuestos: son los que pasan meses sin actualización, con plugins huérfanos y sin nadie mirando los logs. El blanco del scanner no es la fama, es la versión.
El procedimiento que separa actualización de apuesta
El howTo de este artículo trae el paso a paso, y el resumen es el de siempre en una operación seria:
- Inventario de todo el parque: todas las instalaciones con versión de core, plugins y temas, y el responsable de cada una.
- Staging antes de producción: la compatibilidad de plugins es el riesgo real; valide el flujo crítico en la réplica.
- Búsqueda de rastros: logs de acceso buscando traversal y acceso anómalo a plantillas; si lo encontró con el sitio vulnerable, trátelo como incidente.
- Reducción de superficie: menos plugins activos, y un hosting con WAF, scanner y actualización asistida que acorta la ventana en todo el parque.
El ítem 4 es el que escala: gestionar cinco sitios a mano es viable, gestionar cincuenta no. La operación que parchea, prueba y monitorea es la diferencia entre aplicar parche y apostar al parche.
Conclusión
Dos releases críticos de core en un mes no son mala suerte de WordPress: son el precio de sostener la mitad de la web en un año en el que la investigación ofensiva está bien financiada y automatizada.
La respuesta no es abandonar el CMS, es operarlo: core actualizado en staging antes de producción, parque inventariado, plugins mínimos y la capa de hosting acortando la ventana. La falla de septiembre ya tiene parche; la pregunta es cuántos sitios de su parque todavía no lo recibieron.