Esta es una explicación rápida de una vulnerabilidad que se está explotando activamente (incluida en el catálogo KEV de CISA). Describe qué ocurre, quién está afectado y cómo responder, desde la perspectiva del defensor, sin pasos para reproducirla.
- CVE
- CVE-2026-87902 (GHSA-7hp8-65ch-5whp)
- Gravedad
- NVD: CVSS v3.1 8.1 (complejidad de ataque alta) / aviso de WordPress: CVSS v4.0 9.2, Crítica
- Tipo
- Inclusión de archivos (CWE-98) — recorrido de rutas en la resolución de plantillas de página
- Impacto
- Inclusión de archivos .php fuera del tema; RCE cuando coinciden las condiciones del tema y del servidor
- Condiciones previas
- Sin autenticación, sin interacción del usuario
- Afectado
- WordPress 4.7.0–7.1.1
- Corrección
- 7.1.2, publicada el 22 de septiembre de 2026, con correcciones para todas las ramas hasta la 4.7
- Explotación
- En el catálogo KEV de CISA (añadida el 25 de septiembre de 2026, plazo de corrección hasta el 28 de septiembre), marcada como que requiere análisis forense
¿Qué tan peligroso es esperar?
WordPress es el CMS más utilizado, y este fallo abarca unos diez años de versiones, sin autenticación y sin interacción del usuario. Una firma de seguridad especializada en WordPress informa de que los sondeos comenzaron el día en que se publicó la corrección, pasaron a intentos de ejecución de código al día siguiente y se integraron en herramientas de escaneo de uso general. El escaneo es indiscriminado; el tamaño de su sitio no importa.
¿Qué tipo de fallo es?
WordPress decide qué archivo de plantilla muestra una página buscándolo en los directorios del tema. Según el aviso, esa resolución de plantillas de página tenía una brecha: un atacante sin autenticación podía hacer que incluyera un archivo .php fuera de los directorios del tema activo. Cuando un valor externo decide qué archivo se carga, eso es inclusión de archivos (CWE-98). Este sitio no describe cómo se explota.
Por sí sola, esa situación no es ejecución de código. El aviso separa las condiciones para la RCE en un lado del tema y un lado del servidor.
Condición del tema (según el aviso)
- El tema padre o hijo activo tiene un directorio de primer nivel cuyo nombre empieza por
page-(por ejemplo,page-templates) - El aviso indica que esto se aplica a los temas heredados Twenty Twelve y Twenty Fourteen y a algunos temas populares de terceros como Neve, Hestia y Sydney (el fallo está en el manejo del núcleo, no en los temas)
Condición del servidor (según el aviso)
- Existe en el servidor un archivo .php que se comporta de forma peligrosa al incluirse y es legible por la cuenta del servidor web
- Tener
register_argc_argvactivado facilita mucho que se cumpla esta condición - El aviso indica que la imagen oficial de PHP para Docker y la configuración predeterminada de cPanel con PHP anterior a la 8.5 están afectadas
① Fallo del núcleo: se puede incluir un .php fuera del tema
→ corregido en 7.1.2 (y en la versión de cada rama)
② Condición del tema: un directorio que empieza por page-
→ difícil de saber por sí mismo; no confíe en juzgarlo
③ Condición del servidor: un .php peligroso es legible y register_argc_argv está activado
→ desactivar la opción impide toda esa clase de ataque
Quién está afectado
| Rama | Afectadas | Corregida |
|---|---|---|
| 7.1 | 7.1.0–7.1.1 | 7.1.2 |
| 7.0 | 7.0.0–7.0.5 | 7.0.6 |
| 6.9 | 6.9.0–6.9.8 | 6.9.9 |
| 6.8 | 6.8.0–6.8.9 | 6.8.10 |
| 6.7 a 4.7 | hasta la versión anterior a la corrección de cada rama | la corrección de cada rama (6.7.9 … 4.7.37) |
| Anteriores a 4.7 | — | Sin corrección (sin soporte) |
Qué hacer
Compruebe su versión y pase a la versión corregida (primera prioridad)
En el panel, vaya a Escritorio → Actualizaciones y revise la versión. Si no es la 7.1.2 (o la versión corregida de su rama), actualice hoy. Solo la última versión tiene soporte activo, así que 7.1.2 es el objetivo más seguro.
Localice los sitios que las actualizaciones automáticas no alcanzan
En los sitios que admiten actualizaciones en segundo plano, la actualización se inicia sola. El riesgo está en los sitios fuera de esa vía: actualizaciones automáticas desactivadas, núcleo fijado en Git o en una imagen de contenedor (si lo actualiza y luego se reconstruye, la versión antigua vuelve sin aviso), actualizaciones bloqueadas por el alojamiento y el sitio antiguo que nadie recuerda. Si gestiona varios sitios, revise cada uno (lista de comprobación de inventario de seguridad).
Desactive register_argc_argv de PHP (defensa en profundidad)
PHP que atiende peticiones web casi nunca necesita este ajuste. Establezca register_argc_argv = Off en php.ini (o en la configuración de PHP de su alojamiento); si usa contenedores, revise la configuración de la imagen. No sustituye a la actualización, pero corta una vía desde la inclusión de archivos hasta la ejecución de código que va mucho más allá de este CVE.
Compruebe si ya fue vulnerado antes de actualizar
Si un sitio siguió sin parchear después del 22 de septiembre, considere sospechosa esa ventana; CISA también marca este CVE para análisis forense. Como mínimo, revise: (1) archivos .php desconocidos en /tmp, /var/tmp o dentro de wp-content; (2) peticiones en los registros de acceso que contengan recorrido de directorios codificado en porcentaje (el equivalente a ../); (3) usuarios administradores o plugins añadidos recientemente que no reconozca.
Si algo parece mal, no se quede en «parcheado»
Si pudo ejecutarse código, el parche no elimina los archivos ya colocados en el servidor ni las claves ya robadas. Rote la contraseña de la base de datos y las claves de autenticación y salts en wp-config.php, las contraseñas de administrador y las claves de API de terceros, y elimine los archivos sospechosos. El proceso completo está en el manual de remediación de vulnerabilidades y en seguridad de WordPress.
Opinión de este sitio: en cuanto se publica una corrección, los ataques empiezan de inmediato
En el reciente caso de Adobe Commerce, pasaron 44 días entre la corrección y KEV. Aquí fueron tres. La diferencia está en lo fácil que resulta deducir el ataque a partir del diff del parche y en cuántos sitios usan el producto. Según la cronología informada, los sondeos con la forma del diff comenzaron el mismo día en que se publicó la corrección.
La lección: en un producto muy extendido, una corrección no le da tiempo extra. Los atacantes empiezan a trabajar en ella en cuanto se publica, y es difícil que las personas lo sigan a mano. Por eso este sitio considera que asegurarse de que las actualizaciones automáticas lleguen de forma fiable es más importante que el propio proceso de parcheo. Los sitios que recibieron la actualización automática estaban protegidos antes de que sus propietarios supieran que algo había pasado. Los sitios en riesgo son los que no se dan cuenta de que quedan fuera de las actualizaciones automáticas.
Un punto más: la EPSS era del 3%. La EPSS es útil, pero se retrasa con los fallos recién divulgados. Cuando KEV y la EPSS discrepan, haga caso a KEV: es el hecho confirmado.
Fuentes
- WordPress — GHSA-7hp8-65ch-5whp (versiones afectadas y corregidas, condiciones previas de la RCE, CVSS v4.0 9.2)
- WordPress.org — Lanzamiento de WordPress 7.1.2 (22 de septiembre de 2026; retroportes a 4.7, actualizaciones automáticas)
- NVD — CVE-2026-87902 (CWE-98, CVSS v3.1 8.1)
- CISA KEV — Catálogo de vulnerabilidades explotadas conocidas (añadida el 25 de septiembre de 2026, plazo hasta el 28 de septiembre, análisis forense requerido)
- FIRST — EPSS (0,029 el 25 de septiembre de 2026)
- Informe de observación — Patchstack (sondeos desde el día de la corrección, intentos de ejecución de código al día siguiente; este artículo usa solo la cronología y las comprobaciones del lado del defensor)
Lea después
- Práctica: Seguridad de WordPress / El manual de remediación de vulnerabilidades
- Decisión: Priorizar con CVSS, EPSS y KEV
- El caso contrario: CVE-2026-71362 (Adobe Commerce: KEV 44 días después de la corrección)
- Términos: ¿Qué es la RCE? / ¿Qué es el recorrido de rutas?