WordPress CVE-2026-87902: ya la explotan, actualizá a 7.1.2

El 25 de septiembre CISA agregó CVE-2026-87902 a su catálogo de vulnerabilidades explotadas, con plazo de corrección al 28 de septiembre. Lo que la distingue de casi todo lo que se publica sobre WordPress es dónde está la falla: no es un plugin ni un tema de terceros, es el núcleo.

El aviso del propio proyecto, GHSA-7hp8-65ch-5whp, la titula "Unauthenticated path traversal in page-template resolution leading to conditional RCE" y la clasifica como crítica. En castellano: un atacante sin credenciales puede hacer que WordPress, al resolver qué plantilla de página usar, incluya y ejecute un archivo .php cualquiera del servidor que esté fuera de las carpetas del tema activo.

La versión que corrige es la 7.1.2, publicada el 22 de septiembre. Y el arreglo se llevó hacia atrás, en palabras de WordPress, "to all branches eligible to receive security fixes (currently through 4.7)": 25 versiones el mismo día, desde la 7.1.2 hasta la 4.7.37.

CVE-2026-87902: el primer intento llegó el mismo día que el parche

La cronología es lo más incómodo de esta falla, y conviene verla separada en dos bloques.

Las dos marcas horarias del día cero son de Patchstack, que las registró en la telemetría de su propio firewall y es una de las fuentes que NVD referencia en la ficha del CVE. No pude confirmar la hora exacta en que se publicó la 7.1.2, así que no puedo decir cuántas horas pasaron entre el parche y el primer intento: lo que sí está confirmado es que fue el mismo día.

Esto le pone número a algo que la guía de seguridad de WordPress de este sitio venía afirmando con datos de la industria: que con una mediana de 5 horas hasta el primer exploit, la ventana para que una persona decida si actualiza o no ya no existe. Acá se ve en un caso concreto y con reloj.

Las tres condiciones que CVE-2026-87902 necesita para ejecutar código

La palabra que usa el aviso es conditional, y es honesta: la falla no lleva sola a ejecución de código. Hacen falta tres cosas a la vez.

La primera condición es la versión, y es la única que se arregla actualizando. Las otras dos merecen detalle.

La del tema, textual del aviso: "The active child or parent theme contains a top-level directory whose name starts with page- (e.g. page-templates)". Y el aviso nombra cuáles: "the legacy Twenty Twelve and Twenty Fourteen themes, as well as some popular third party themes such as Neve, Hestia, and Sydney".

La del servidor es la que conviene leer dos veces si tu sitio está en un hosting compartido: "the default cPanel configuration is affected when PHP prior to 8.5 is in use". El aviso también señala que "the official php image for Docker is affected". El mecanismo concreto que menciona es el paso conocido de pearcmd.php a ejecución de código cuando register_argc_argv está en On.

Acá está lo importante, y es la razón por la que "condicional" no significa "postergable": la tercera condición no la controlás vos. Depende de cómo esté configurado PHP en el servidor de tu proveedor. Un sitio que hoy no cumple la tercera condición puede cumplirla mañana porque el hosting cambió una versión de PHP, y nadie te va a avisar. Es la misma lógica que en Acronis sobre cPanel y Plesk: el panel que te simplifica la vida también decide cosas por vos.

Los cinco temas que nombra el aviso suman 450.000 instalaciones activas

El aviso nombra temas pero no dice cuántos sitios son. Eso se puede consultar en la API pública de wordpress.org, que publica las instalaciones activas de cada tema del directorio oficial.

Dos aclaraciones sobre ese número, porque es mío y no del aviso. La primera: wordpress.org publica las instalaciones activas en tramos redondeados, así que 450.000 es del orden de magnitud, no una cuenta exacta. La segunda, y más importante: el aviso dice "such as", o sea "algunos temas populares como". No es una lista completa, es una muestra. Cualquier tema con una carpeta que empiece con page- cumple la condición, y eso incluye temas comerciales y temas hechos a medida que nadie cuenta.

WordPress dice 9,2 y CISA dice 8,1: la diferencia está en dónde va la condición previa

Si buscás esta falla vas a encontrar dos puntajes distintos, y conviene saber por qué antes de que alguien los use para decidir prioridades.

Los dos vectores dicen lo mismo en casi todo: se ataca por red, sin privilegios y sin que la víctima haga nada, y el impacto es total en confidencialidad, integridad y disponibilidad. La única diferencia real está en cómo cada escala anota la condición previa.

CVSS 4.0 tiene una métrica aparte para eso, Attack Requirements, y la pone en AT:P —presente— mientras deja la complejidad del ataque en AC:L. CVSS 3.1 no tiene esa métrica, así que la misma condición previa no tiene otro lugar donde ir y termina dentro de la complejidad, como AC:H. Y AC:H baja el puntaje.

O sea: no hay desacuerdo sobre la falla, hay dos vocabularios. Pero la consecuencia práctica es concreta: en una planilla ordenada por puntaje, un 8,1 "alto" queda debajo de cosas que importan menos, y un 9,2 "crítico" no. Es el mismo problema que apareció con las cuatro críticas de Check Point, F5 y Arista: comparar un puntaje de una escala contra el de otra no dice nada.

Vale agregar un dato más de la ficha de CISA, que puntúa aparte con un método llamado SSVC: el 25 de septiembre marcó la explotación como activa, el impacto técnico como total y la automatización como no. Ese último punto es coherente con las condiciones previas. Conviene igual ponerlo contra el hecho de que al día siguiente del parche ya circulaba una plantilla de escaneo pública: que un ataque no sea automatizable de punta a punta no impide que encontrar los sitios candidatos sí lo sea.

¿A quién afecta CVE-2026-87902 de WordPress?

A cualquier WordPress autoalojado entre la 4.7.0 y la 7.1.1. Esa horquilla es casi toda la historia moderna del sistema: la 4.7 salió el 6 de diciembre de 2016, así que hablamos de cerca de 10 años de versiones.

En la práctica, en la región, esto es mucho: es el sitio institucional de la PyME, la tienda, el blog que se armó una vez y quedó andando. Y el caso más expuesto es el que tiene las tres condiciones sin saberlo: WordPress viejo, un tema gratuito popular y un hosting compartido con cPanel.

Que la falla sea condicional no cambia el plan. Si se cumplen las tres, es ejecución de código. Si falta la tercera, sigue siendo lectura de archivos del servidor por parte de alguien sin credenciales, y eso alcanza para leer wp-config.php, que es donde están las claves de la base de datos. Es el mismo punto que en el formulario de Elementor Pro que subía un .php: en un sitio web, "solo leer" nunca es solo leer.

¿Quién puede ignorar CVE-2026-87902 sin correr riesgo?

Quien no tenga WordPress autoalojado. Si tu sitio está en WordPress.com —el servicio gestionado, no el software— la actualización del núcleo no pasa por vos.

Y quien ya esté en una de las 25 versiones corregidas. Si tenés las actualizaciones automáticas de núcleo activadas, es probable que ya estés: el anuncio de WordPress dice que "if you have sites that support automatic background updates, the update process will begin automatically". Probable no es seguro, así que igual conviene mirar el número.

Lo que no alcanza para ignorarla: que tu tema no esté en la lista de cinco. La lista es una muestra, no un inventario.

¿Cómo sé si mi WordPress cumple las tres condiciones?

En este orden, que va de lo más fácil a lo más técnico:

1. La versión. Entrá al escritorio, Actualizaciones, y mirá el número. Las corregidas son la 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, y siguen hacia atrás hasta la 4.7.37. Si tu número es menor que el de tu rama, no estás.
2. El tema. Por FTP o en el administrador de archivos del panel, entrá a wp-content/themes/ y abrí la carpeta del tema activo, y la del tema padre si usás uno hijo. Buscá una carpeta cuyo nombre empiece con page-, tipo page-templates. Si está, se cumple la segunda condición.
3. El servidor. En cPanel, en Select PHP Version → Options, buscá register_argc_argv. Si está en On, y tu PHP es anterior a 8.5, estás en la configuración que el aviso nombra. Si no encontrás la opción, preguntale al proveedor: es una pregunta legítima y concreta.

Y para saber si ya te intentaron entrar, hay algo que se puede buscar en los registros de acceso del servidor. Patchstack publicó las señales que observó en su firewall, y son de forma, no de contenido:

• Pedidos con %2e%2e, que es .. codificado.
• El parámetro pagename apareciendo junto con page_id en el mismo pedido.
• Prefijos como templates%2f en esos parámetros.
• Pedidos a archivos del núcleo que casi nadie visita a mano, como wp-links-opml.php o wp-includes/feed-rss2.php, usados para tantear si el sitio es vulnerable.

Encontrar esas cadenas significa que te escanearon, que a esta altura le pasó a casi cualquier sitio. Lo que hay que buscar después es si apareció algún .php nuevo que vos no pusiste, sobre todo en carpetas temporales. Si aparece, el problema ya no es actualizar: es lo que explicaba la nota de GitLab, que el parche cierra la puerta pero no echa a quien ya entró.

¿Qué hago si tengo WordPress en mi servidor?

1. Actualizá el núcleo hoy. Es una sola pantalla y el proyecto lo dice sin vueltas: "because this is a security release, it is recommended that you update your sites immediately". Si tenés miedo de que algo se rompa, hacé la copia de seguridad primero, pero hacela ahora, no el lunes.
2. Activá las actualizaciones automáticas del núcleo si no las tenés. La cronología de esta falla es el argumento: no hubo un día de margen para decidir.
3. Revisá los registros con las cuatro señales de arriba, y buscá archivos .php con fecha de modificación reciente que no reconozcas.
4. Preguntale al hosting por register_argc_argv y por la versión de PHP. Es la condición que no controlás, y la respuesta te dice si tu sitio estuvo en riesgo real o solo teórico estos días.
5. Si el tema es viejo y sin mantenimiento, esta es la excusa para cambiarlo. Twenty Twelve y Twenty Fourteen tienen más de 10 años.

El encuadre más largo de qué parte de esto cubre tu proveedor y qué parte queda de tu lado está en la guía de seguridad de WordPress para PyMEs. La lógica de por qué el software que instalás vos deja el parche en tus manos está en Zimbra y TrueConf. Las opciones de hosting del catálogo están en hostings y cloud, y la experiencia concreta con uno de ellos en la reseña de Hostinger. Los términos, en el glosario.

Preguntas frecuentes sobre CVE-2026-87902 y WordPress 7.1.2

¿Mi sitio ya se actualizó solo o tengo que hacer algo?

Depende de si tenés las actualizaciones automáticas de núcleo activadas, y en muchas instalaciones vienen activadas de fábrica para versiones de seguridad. WordPress dice que en los sitios que las soportan el proceso arranca por sí mismo. Pero hay razones frecuentes por las que no pasa: una constante puesta a mano en wp-config.php, permisos de archivo que impiden escribir, o un plugin de mantenimiento que las bloquea. La única forma de saberlo es mirar el número de versión en el escritorio.

Mi tema no es ninguno de los cinco que nombran. ¿Estoy a salvo?

No necesariamente. El aviso dice "algunos temas populares de terceros como", y esa lista es una muestra. La condición real es que el tema activo o su tema padre tenga una carpeta de primer nivel cuyo nombre empiece con page-. Eso lo comprobás entrando a la carpeta del tema y mirando, y es más confiable que buscar tu tema en una lista.

Si la falla es condicional, ¿puedo esperar al fin de semana para actualizar?

La cronología dice que no. El primer intento de explotación se registró el mismo día que salió el parche, y al día siguiente ya circulaba herramienta pública para buscar sitios vulnerables. Además, la condición del servidor no la controlás: depende de la configuración de PHP de tu proveedor, y puede cambiar sin que vos hagas nada. Un sitio que hoy no es explotable puede serlo la semana que viene sin que nadie toque el sitio.

¿Por qué WordPress dice 9,2 crítica y otras fuentes dicen 8,1 alta?

Porque están usando dos escalas distintas y no pueden compararse. WordPress puntúa en CVSS 4.0, que tiene una métrica separada para las condiciones previas y la anota ahí. CISA puntúa en CVSS 3.1, que no tiene esa métrica, así que la condición previa termina contada como mayor complejidad de ataque y eso baja el número. Es la misma falla descrita dos veces. NVD, por su parte, todavía no le puso puntaje propio: su ficha figura como Undergoing Analysis.

Tengo WordPress 5.4 porque el sitio es viejo y no lo puedo actualizar de rama. ¿Quedé afuera del parche?

No. Esta vez el arreglo se llevó hacia atrás hasta la rama 4.7, así que hay una versión corregida para casi cualquier rama que estés usando: para la 5.4 es la 5.4.23. Eso te resuelve esta falla puntual sin cambiar de rama. Lo que no resuelve es el resto: una rama vieja solo recibe correcciones de seguridad, no todas las de las ramas nuevas, y los plugins y temas van dejando de soportarla.