CVE-2026-87902: el exploit de WordPress que deja tu web en blanco

Durante los últimos días, una nueva vulnerabilidad ha puesto en jaque a miles de instalaciones de WordPress y ClassicPress. Se cataloga como CVE-2026-87902 y su explotación es automatizada: bots que recorren la web probando el exploit de forma masiva, sin necesidad de contraseña ni de una cuenta en el sitio.

El síntoma más llamativo no parece un ataque en absoluto: de un momento a otro, la portada deja de cargar y en su lugar aparece una página casi en blanco con una fecha. Detrás de esa pantalla inofensiva se esconde un fallo grave de inclusión de ficheros que, en el peor de los casos, permite ejecutar código en el servidor.

En este artículo explicamos qué es exactamente CVE-2026-87902, cómo funciona, qué ocurrió en un caso real que hemos podido analizar de cerca —con un final más tranquilo de lo que pintaba— y, sobre todo, cómo proteger tu sitio paso a paso.

¿Qué es la vulnerabilidad CVE-2026-87902?

CVE-2026-87902 es una vulnerabilidad de inclusión de ficheros locales —conocida por sus siglas en inglés, LFI (*Local File Inclusion*)— que no requiere autenticación.

El problema está en la forma en que el gestor resuelve las plantillas de página: el valor `pagename` de la URL se utiliza sin validar como uno de los nombres de plantilla candidatos.

Un atacante puede aprovecharlo para introducir un salto de directorio (*path traversal*) y forzar la inclusión de ficheros arbitrarios del servidor.

Afecta a WordPress desde la versión 4.7 y también a ClassicPress, lo que abarca un enorme parque de sitios. Al no exigir credenciales, es carne de explotación automatizada: basta con lanzar la petición maliciosa contra cualquier dominio.

De incluir un fichero a ejecutar código: el papel de pearcmd

Por sí sola, una inclusión de ficheros permite leer archivos del servidor, lo que ya es grave (por ejemplo, el `wp-config.php` con las credenciales de la base de datos). Pero el riesgo real llega cuando se encadena con otro componente.

Si el contenedor incluye `pearcmd.php` —parte de la librería PEAR— y PHP tiene activada la opción `register_argc_argv`, es posible usar el LFI para escribir un fichero con código propio y luego incluirlo, obteniendo ejecución remota de código (RCE).

Muchas imágenes oficiales de PHP cumplen justo esas condiciones sin que el administrador lo sepa, de modo que un fallo aparentemente de “solo lectura” se convierte en control total del servidor.

Las versiones que corrigen el fallo

La única solución de raíz es actualizar el núcleo. Los equipos de WordPress y ClassicPress publicaron parches el 22 de septiembre de 2026.

En WordPress, las versiones corregidas son la 7.1.2, 7.0.6, 6.9.9 y 6.8.10, además de *backports* hasta la 4.7.37 para instalaciones muy antiguas.

En ClassicPress, la versión 2.7.3 restringe el salto de directorio en la función `locate_template()`. Si tu sitio corre una versión anterior a estas, es vulnerable y deberías actualizar cuanto antes: mientras no lo hagas, cualquier otra medida es solo contención temporal.

Un caso real: la web que amaneció en blanco

En un incidente real reciente, lo primero que se detectó no fue una alerta de seguridad, sino algo mucho más desconcertante: la portada del sitio dejó de mostrarse.

En su lugar cargaba una página prácticamente vacía, con poco más que una fecha en pantalla. A simple vista parecía un error del servidor o un problema del tema, no un ataque.

Esa es una de las características más traicioneras de este caso: el resultado visible se confunde con una avería, y quien administra el sitio puede perder un tiempo valioso buscando en el lugar equivocado antes de sospechar que ha sido objetivo de un exploit.

La causa: la caché envenenada con una respuesta OPML

El origen de esa pantalla en blanco fue un envenenamiento de la caché. La petición del exploit no tenía una URL canónica normal, así que el plugin de caché calculó la clave sobre una petición prácticamente “vacía” y guardó una salida en formato OPML —un XML pensado para listas de *feeds*— bajo la misma clave que corresponde a la portada.

A partir de ese momento, cada visitante recibía esa respuesta OPML cacheada en lugar de la home real. El sitio no estaba “roto” en disco: seguía intacto. Simplemente servía una respuesta envenenada guardada en caché, y bastó con purgar esa caché para recuperar la portada.

El desenlace: una intrusión contenida

Aquí está la parte tranquilizadora. El análisis forense confirmó que el LFI funcionó —se pudieron incluir ficheros legítimos del núcleo— y que, mediante la técnica de `pearcmd`, se llegó a escribir un pequeño fichero en el almacenamiento temporal del contenedor.

Pero el *payload* de ejecución nunca se activó: no hubo ejecución de código, no quedó ninguna puerta trasera ni fichero modificado en el sitio, y la base de datos quedó intacta, sin usuarios administradores nuevos ni cambios en la configuración.

El fichero escrito vivía en `/tmp`, un almacenamiento efímero que desaparece al recrear el contenedor. Varios factores lo contuvieron: uno de los atacantes intentó incluir un fichero de PHPUnit que no estaba instalado, y la instalación tenía bloqueadas las peticiones externas, lo que habría limitado mucho lo que una *shell* podría descargar o exfiltrar.

En resumen: intrusión detectada, con escritura de un artefacto temporal, pero sin ejecución de código, sin persistencia y sin robo de datos.

¿Cómo saber si tu sitio ha sido atacado?

Este exploit deja un rastro reconocible. En los logs del servidor aparecen peticiones con el parámetro `pagename` seguido de un salto de directorio codificado, con una forma similar a `pagename=templates%252F%252E%252E…` (la doble codificación es precisamente lo que esquiva los filtros ingenuos).

En el caso analizado, uno de los atacantes se identificó incluso con un *user-agent* revelador, `cve-2026-87902-poc/1.0`, y hubo reconocimiento previo contra la REST API (`/wp/v2/pages`).

Si encuentras estas huellas en tus registros, has sido escaneado o atacado; conviene revisar con calma si el intento llegó a algo más que a un simple sondeo.

Revisa la caché aunque el ataque falle

Una lección importante del caso: aunque el intento de ejecución fracase, el envenenamiento de caché puede dejar tu web caída por su cuenta. Es decir, puedes estar protegido contra la parte grave (la RCE) y aun así ver tu portada en blanco por el efecto secundario en la caché.

Por eso, tras cualquier intento sospechoso, verifica el estado de la caché y púrgala si es necesario. Dependiendo de tu configuración, puede tratarse de un fichero en disco o de una entrada en un sistema en memoria como memcached, que a veces se resuelve simplemente reiniciando el servicio.

Cómo proteger tu WordPress o ClassicPress

Actualiza el núcleo: la solución de raíz

No hay atajo que sustituya a esto. Actualiza a la versión parcheada de tu rama (ClassicPress 2.7.3 o superior; WordPress 7.1.2, 7.0.6, 6.9.9, 6.8.10 o el *backport* que corresponda).

Es la única medida que elimina la vulnerabilidad de verdad; todo lo demás son capas de contención que compran tiempo pero no cierran el fallo.

Añade una regla de bloqueo en el servidor web

Como defensa en profundidad —útil incluso después de parchear— puedes bloquear en el propio servidor web las peticiones que intenten el salto de directorio en `pagename`. En nginx, una regla tan sencilla como esta devuelve un 403 al exploit sin afectar al tráfico legítimo:

“`nginx
if ($args ~* “pagename=[^&]*(\.\.|%2e|%25)”) { return 403; }
“`

Colócala en la configuración de cada sitio y comprueba que el exploit recibe un 403 mientras la portada sigue respondiendo con normalidad.

Elimina pearcmd.php y apóyate en un WAF

Si usas contenedores basados en imágenes oficiales de PHP, elimina `pearcmd.php` de la imagen: es el componente que convierte un LFI de lectura en escritura de ficheros y, por tanto, en RCE. Quitarlo corta esa vía aunque el LFI siga existiendo.

Por último, un WAF añade otra capa más: en Cloudflare, por ejemplo, puedes crear reglas personalizadas (disponibles en el plan gratuito) para bloquear las IPs y los patrones asociados a este ataque. Combinar núcleo actualizado + regla en el servidor + WAF te deja tres barreras independientes.

Lecciones del incidente para cualquier administrador

Frente a exploits automatizados, la velocidad lo es todo

Este CVE se explota de forma masiva y automatizada: no hace falta que alguien te elija como objetivo, basta con que un bot pase por tu dominio.

En el caso analizado se siguieron observando intentos incluso después de aplicar la mitigación (todos rechazados con 403).

La diferencia entre un susto y un desastre suele medirse en horas: cuanto antes apliques el parche desde que se publica, menos ventana das a que el exploit prospere.

La defensa en profundidad convierte un fallo en un susto controlado

Si algo enseña este incidente es que las capas suman. El ataque logró escribir un fichero, pero no ejecutarlo; envenenó la caché, pero no tocó los datos.

Ese final tranquilo no fue casualidad: fue la consecuencia de varias barreras —dependencias ausentes, peticiones externas bloqueadas, almacenamiento temporal efímero— que impidieron que un paso fallara hacia el siguiente.

Ninguna medida individual es infalible, pero juntas hacen que un fallo grave se quede en un simple sobresalto.

Rota credenciales si el LFI pudo leer tu wp-config.php

Como el LFI permite leer ficheros del servidor, siempre existe la posibilidad de que un atacante haya llegado a ver el `wp-config.php`, donde viven las credenciales de la base de datos y las claves de seguridad.

Por prudencia, tras un intento confirmado conviene rotar esas credenciales: contraseña de la base de datos, *salts* y claves de WordPress, y cualquier otra clave sensible que el sitio guarde en configuración.

Es una molestia menor comparada con dejar unas credenciales potencialmente expuestas.

En resumen

CVE-2026-87902 es un buen recordatorio de que las vulnerabilidades más peligrosas no siempre se anuncian con una pantalla dramática: a veces solo dejan una web en blanco con una fecha.

La combinación de un LFI sin autenticación con el *gadget* de PEAR la convierte en una puerta a la ejecución de código, pero un núcleo actualizado y unas cuantas capas de defensa bastan para cerrarla.

Si gestionas cualquier instalación de WordPress o ClassicPress, actualiza hoy mismo, añade la regla de bloqueo y revisa tus logs y tu caché. El caso que hemos analizado terminó bien precisamente porque se actuó rápido y había defensas en varios niveles.