WordPress 7.1.2 y CVE-2026-87902: cómo verificar una cartera

Respuesta corta: WordPress 7.1.2 corrige CVE-2026-87902, una vulnerabilidad de inclusión de archivos PHP sin autenticación que, bajo determinadas condiciones del servidor y del tema activo, puede terminar en ejecución remota de código. No basta con confiar en la actualización automática: si gestionas una cartera, debes verificar la versión corregida sitio por sitio y revisar la ventana de exposición de cualquier web que permaneciera vulnerable.

Actualizado el 30 de septiembre de 2026. Este artículo está dirigido a agencias, freelancers y equipos que operan varias instalaciones WordPress. Distingue hechos publicados por WordPress, el registro CVE, CISA y Patchstack de un procedimiento editorial de respuesta. No sustituye un análisis forense del servidor.

Qué ha cambiado desde WordPress 7.1.1

WordPress publicó la versión 7.1.2 el 22 de septiembre como una actualización exclusivamente de seguridad. La nota oficial recomienda actualizar inmediatamente y explica que un atacante no autenticado puede hacer que la resolución de plantillas incluya un archivo PHP local legible situado fuera de los directorios del tema activo. Cuando coinciden ciertas condiciones del servidor y del tema, esa inclusión puede escalar a ejecución remota de código.

La diferencia operativa frente a la versión 7.1.1 publicada cinco días antes es importante: 7.1.1 ya no debe figurar como «actualizada» en una cartera. El estado que importa ahora es la versión corregida más reciente de cada rama.

Dato	Evidencia disponible	Decisión para una agencia
Producto	WordPress Core	Revisar toda la cartera, no solo sitios con un plugin concreto.
Identificador	CVE-2026-87902 / GHSA-7hp8-65ch-5whp	Usar el identificador para relacionar inventario, logs y tickets.
Versiones	El registro CVE marca como afectadas las anteriores a 7.1.2 y documenta backports hasta la rama 4.7.	Comprobar la versión corregida efectiva de la rama instalada; no exigir un salto mayor sin probar compatibilidad.
Acceso requerido	No requiere autenticación.	Priorizar sitios públicos y no retrasar la actualización al siguiente mantenimiento mensual.
Impacto	Inclusión de un PHP local legible; RCE si se cumplen condiciones adicionales.	No describir cada intento como compromiso, pero tampoco cerrar el caso solo porque la web sigue funcionando.
Explotación	Patchstack observó intentos el mismo día del parche y después escritura de archivos PHP; CISA añadió la CVE a KEV el 25 de septiembre.	Tratar los sitios expuestos como una revisión de incidente, no como una actualización rutinaria.

Qué significa «RCE condicional»

El registro CVE no afirma que cualquier instalación vulnerable permita ejecutar código de forma automática. El fallo permite incluir un archivo .php local legible fuera del tema activo; la ejecución remota depende de condiciones adicionales del entorno del servidor y del tema.

Esto obliga a separar tres estados:

1. Vulnerable: la instalación ejecutaba una versión sin corregir.
2. Explotable en ese entorno: además existían las rutas y condiciones necesarias para alcanzar una inclusión útil.
3. Comprometida: hay evidencia de que un atacante consiguió ejecutar o escribir código.

No observar un archivo malicioso no convierte automáticamente un sitio en seguro. Y encontrar una petición de reconocimiento tampoco demuestra por sí sola que la ejecución se completara. La respuesta debe conservar esa incertidumbre hasta revisar evidencia suficiente.

Por qué actualizar no cierra el incidente

Patchstack documentó solicitudes contra el fallo el 22 de septiembre, el mismo día de la publicación. El 23 de septiembre actualizó su análisis tras observar inclusiones de pearcmd.php usadas para escribir archivos PHP en directorios temporales. El volumen observado aumentó y los payloads variaron en método, codificación y profundidad.

El 25 de septiembre, CISA incorporó CVE-2026-87902 a su catálogo KEV y marcó la necesidad de triaje forense. KEV confirma explotación conocida; no cuantifica cuántas webs WordPress fueron comprometidas ni demuestra que una web concreta lo esté.

Por tanto, el parche resuelve la puerta de entrada, pero no responde a la pregunta histórica: ¿qué ocurrió mientras el sitio todavía era vulnerable?

Procedimiento para verificar una cartera WordPress

El siguiente flujo es criterio editorial para equipos multi-sitio. Adáptalo a tu hosting, retención de logs, criticidad del cliente y obligaciones contractuales.

1. Fija el denominador real

Empieza por el número total de sitios que debían recibir la revisión. No informes «todo actualizado» a partir de los sitios que respondieron. Separa al menos:

• versión corregida confirmada;
• versión vulnerable confirmada;
• sitio inaccesible o sin telemetría reciente;
• versión desconocida;
• excepción temporal con responsable y fecha límite.

Un sitio que dejó de comunicar no está actualizado: su estado es desconocido. Si este problema aparece con frecuencia, conviene revisar cómo detectar huecos de monitorización en la cartera.

2. Actualiza y comprueba la versión efectiva

Aplica WordPress 7.1.2 o la versión corregida de la rama que corresponda. Después vuelve a leer la versión desde el sitio o desde una fuente independiente del comando de actualización. Un proceso aceptado por el panel, una tarea programada ejecutada o un HTTP 200 no prueban que el core activo sea el corregido.

En sitios de alta criticidad, prueba login, publicación, formularios, compra y cualquier flujo ligado al tema. La seguridad no justifica ocultar una regresión funcional; la regresión tampoco justifica mantener una versión expuesta sin una decisión y un control compensatorio explícitos.

3. Delimita la ventana de exposición

Para cada sitio que estuvo en una versión vulnerable, registra cuatro momentos: primera fecha razonable de exposición, publicación del parche, actualización efectiva y última evidencia revisable. Si la retención de logs no cubre toda la ventana, declara el hueco. No lo rellenes con «sin indicios».

Pregunta	Evidencia útil	Salida
¿Cuándo quedó corregido?	Versión observada y marca temporal verificable.	Fin de la ventana vulnerable.
¿El sitio recibió intentos?	Logs web y WAF, incluyendo GET y POST y variantes codificadas.	Sin registros / intento bloqueado / petición procesada.
¿Hubo inclusión o escritura?	Respuestas anómalas, cambios de archivos, procesos y directorios temporales.	Sin evidencia / señal investigable / compromiso confirmado.
¿La cobertura es completa?	Retención, relojes sincronizados y fuentes disponibles.	Confianza alta, media o insuficiente.

4. Busca señales sin depender de una única cadena

Patchstack advierte que las solicitudes observadas cambiaban entre GET y POST, codificaciones y profundidades de traversal. Una regla basada en un solo payload puede perder variantes. Revisa el comportamiento: parámetros ligados a la resolución de página y plantilla, respuestas inesperadas, inclusión de archivos PHP locales, escrituras inusuales y procesos asociados.

La revisión de /tmp y /var/tmp puede aportar evidencia en servidores donde tengas acceso, pero no es una prueba universal. Los contenedores, reinicios, permisos y la retención del proveedor pueden haber eliminado o aislado artefactos. Si encuentras un PHP inesperado o ejecución confirmada, preserva evidencia antes de borrar y escala el sitio como comprometido.

5. Separa actualización, triaje y recuperación

Estado	Acción mínima	Criterio de cierre
Corregido, sin exposición verificable	Registrar versión y prueba funcional.	Versión efectiva confirmada y cobertura documentada.
Corregido, con ventana expuesta	Revisar logs, archivos, procesos y cuentas privilegiadas según riesgo.	Evidencia revisada, límites declarados y riesgo residual aceptado.
Intentos observados, sin ejecución probada	Preservar logs, ampliar búsqueda y validar controles.	Alcance razonable y ausencia de señales posteriores, sin convertirlo en certeza absoluta.
Escritura o ejecución confirmada	Aislar, preservar, erradicar persistencia, rotar secretos y recuperar desde una base fiable.	Recuperación verificada y seguimiento reforzado.
Sin telemetría suficiente	Tratar como incertidumbre operativa y elevar según criticidad.	No cerrar como «limpio»; documentar la limitación.

Qué debería recibir el cliente

Evita un mensaje binario como «actualizado, solucionado». Un informe útil debe incluir:

• sitios incluidos y sitios sin cobertura;
• versión corregida observada y hora de verificación;
• ventana vulnerable estimada;
• fuentes de evidencia revisadas;
• señales encontradas o ausencia de ellas;
• limitaciones de retención y acceso;
• acciones realizadas, responsable y siguiente revisión.

Ese formato permite distinguir despliegue de parche, investigación y cierre. También encaja con un contrato de cierre basado en evidencia en lugar de cerrar tickets por intuición.

Dónde encaja Vulnity y dónde no

Vulnity ayuda a centralizar señales operativas y el estado de varias webs WordPress, aplicar hardening y reducir el trabajo sitio por sitio. Ese contexto puede ayudarte a detectar sitios silenciosos, ordenar alertas y mantener una vista común para la respuesta.

Vulnity no detecta CVEs ni identifica plugins, temas o versiones de WordPress vulnerables. Tampoco sustituye el parche, un WAF, el análisis de malware, los logs completos del servidor, los backups probados ni una investigación forense. Para CVE-2026-87902 necesitas confirmar la versión por una fuente adecuada y revisar la evidencia del hosting o de tus herramientas de seguridad.

Si gestionas varios WordPress: prueba Vulnity para centralizar señales, hardening y respuesta operativa. Úsalo como capa de visibilidad; no como sustituto de la inteligencia de vulnerabilidades ni del triaje de este incidente.

Fuentes y límites

• WordPress.org: WordPress 7.1.2 Release.
• Aviso de seguridad oficial GHSA-7hp8-65ch-5whp.
• Registro CVE-2026-87902.
• CISA Known Exploited Vulnerabilities Catalog.
• Patchstack: observación de explotación y evolución de payloads.

Las observaciones de Patchstack describen tráfico visto por su infraestructura, no todas las instalaciones WordPress. La inclusión en KEV acredita explotación conocida, pero no atribuye compromiso a una web concreta. Los pasos de priorización, verificación y cierre de este artículo son juicio editorial para carteras multi-sitio.