WordPress: falla crítica 9.2/10 presente desde 2016

WordPress corrige una vulnerabilidad crítica (CVSS 9.2) presente desde 2016

El 22 de septiembre de 2026, el equipo de seguridad de WordPress publicó el aviso GHSA-7hp8-65ch-5whp con una puntuación CVSS de 9.2 sobre 10: la falla CVE-2026-87902, una vulnerabilidad de path traversal sin autenticación que ha estado latente en el núcleo del CMS desde la versión 4.7, lanzada en diciembre de 2016. Un atacante remoto sin credenciales puede, en condiciones concretas, encadenarla hasta conseguir ejecución remota de código (RCE) en el servidor.

La vulnerabilidad fue descubierta y reportada de forma responsable por el investigador Robert Ressl, según consta en el advisory publicado en GitHub. El equipo de WordPress no solo corrigió el código en la rama actual (7.1.2), sino que hizo backport del parche a todas las ramas soportadas hasta la 4.7, algo que, en la práctica, deja a cualquier instalación de WordPress con un camino claro de mitigación, sin importar lo antigua que sea.

¿Qué es CVE-2026-87902 y cómo funciona?

El fallo reside en la función get_page_template(), parte del mecanismo que decide qué plantilla PHP se carga al renderizar una página. La función no restringe correctamente el componente de ruta que recibe, lo que permite a un atacante escapar del directorio de plantillas del tema activo y hacer que WordPress incluya cualquier archivo .php legible por la cuenta del servidor web.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Por sí solo, el path traversal no siempre termina en RCE. La ejecución remota solo se materializa cuando se cumplen dos precondiciones simultáneas en el entorno del sitio:

El tema activo (padre o hijo) contiene un directorio de primer nivel cuyo nombre empieza por page-, por ejemplo page-templates. Es el caso de los temas clásicos Twenty Twelve y Twenty Fourteen que aún se usan en miles de sitios, y de terceros populares como Neve, Hestia y Sydney.
Existe en el servidor un archivo .php legible por la cuenta web que el atacante pueda apuntar como destino. Aquí entra la vieja pero persistente técnica de pearcmd.php (el binario CLI de PEAR) cuando PHP está configurado con register_argc_argv = On. El equipo de WordPress advierte explícitamente que la imagen oficial de php para Docker se ve afectada, y que la configuración por defecto de cPanel con PHP anterior a 8.5 también lo está.

Es decir, no es un exploit de un solo clic contra cualquier instalación, pero la combinación Docker + tema con directorio page- es endémica en sitios modernos.

¿Quiénes están en riesgo hoy?

Más de una década de código está afectada: todas las versiones desde 4.7 hasta las publicadas justo antes del parche, incluidas 5.0, 5.5, 6.0, 6.4, 6.7, 7.0 y 7.1, entre muchas otras. La lista completa de versiones vulnerables y parcheadas incluye 26 ramas; el advisory las enumera una por una.

Versiones parcheadas disponibles el 22 de septiembre de 2026:

7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32, 4.7.37.

Es la primera vez en mucho tiempo que el equipo de seguridad backportea un parche crítico a tantas ramas históricas de forma simultánea, lo que en sí mismo es una señal de la gravedad percibida.

Por qué importa: WordPress sigue sosteniendo la web

Que una vulnerabilidad crítica afecte a "todas las versiones desde 2016" deja de ser un dato histórico cuando WordPress sigue siendo, por un margen enorme, el CMS más usado del mundo. Según los datos de HTTP Archive procesados por GravityKit con el crawl de abril de 2026, WordPress está presente en el 33,21% de los orígenes web medibles (muestra móvil de CrUX, alrededor de 8,9 millones de sitios). El segundo, Shopify, se queda en el 4,74%. Entre los diez primeros CMS, solo Shopify, Wix, Squarespace y Webflow ganaron cuota el último año; WordPress, Drupal, Joomla, PrestaShop, Tilda y 1C-Bitrix la perdieron.

Eso significa que cualquier hueco crítico en core WordPress golpea, en términos absolutos, a decenas de millones de sitios: desde blogs personales hasta e-commerce, sitios de medios y backends de pequeñas empresas. La cadena de precondiciones (Docker por defecto + tema con page-) es exactamente el tipo de configuración que un founder técnico replica sin pensarlo al levantar un blog o un MVP rápido.

¿Qué significa esto para tu startup?

Si tu producto, landing o e-commerce corre sobre WordPress (en hosting compartido, VPS o contenedor Docker), el 22 de septiembre de 2026 es uno de esos días en los que conviene abrir el dashboard y actualizar, aunque sea una versión que lleves años sin tocar.

Acciones concretas que puedes tomar hoy:

Actualiza el core inmediatamente a la versión parcheada de tu rama (7.1.2, 7.0.6, 6.9.9, 6.8.10, etc., según la que estés usando). El advisory lista las 26 versiones parcheadas, así que no hay excusa: cubre incluso ramas de 2017.
Audita los temas activos y comprueba si tienen un directorio cuyo nombre empiece por page- (por ejemplo page-templates). Si usas Twenty Twelve, Twenty Fourteen, Neve, Hestia o Sydney (todos mencionados en el aviso), plantéate migrar a un tema mantenido o aplicar el parche con urgencia.
Revisa tu configuración PHP en producción: si tu php.ini tiene register_argc_argv = On (es el valor por defecto en muchas imágenes Docker de PHP y en cPanel con PHP < 8.5), desactívalo o documenta que estás expuesto a la cadena RCE completa.

Para founders que construyen sobre WordPress como plataforma:

Clientes y SLA: si vendes sitios WordPress a clientes, este es un incidente de seguridad que justifica una comunicación proactiva. No esperes a que te llamen.
Plugins propios: si tu plugin llama a get_page_template() o interactúa con la resolución de plantillas, revisa si arrastra algún patrón similar. El aviso describe la clase de bug, no solo el caso puntual.
Migración a headless: la cuota de WordPress lleva cuatro años cayendo lentamente desde su pico de 35,76% en julio de 2022 según HTTP Archive / GravityKit. Si tu stack depende de mantener WordPress por legacy, esta clase de disclosures son un argumento más para planificar una salida gradual a un stack headless o a un CMS moderno, especialmente si tu producto se sostiene sobre SLA de seguridad.

La regla práctica, en cualquier caso, se mantiene: en WordPress, el riesgo no está en el plugin de turno, sino en el core. Y hoy, el core acaba de enseñar una costura que llevaba una década abierta.