Si administras sitios con WordPress, esta semana no es de mirar solo el panel de actualizaciones y seguir: el parche del 22 de septiembre llegó tarde para muchos bots. CVE-2026-87902 es un fallo crítico en la resolución de plantillas de página que, bajo ciertas condiciones del tema y del servidor, puede acabar en ejecución remota de código sin que nadie haya iniciado sesión. Yo lo tengo presente en cada revisión de cliente porque no afecta por igual a todos los proyectos.
WordPress publicó la corrección en la 7.1.2 (y en decenas de ramas antiguas). Según el seguimiento de webhosting.today, los primeros intentos de explotación se registraron el mismo día del parche, a las 11:49 UTC, y el primer intento de escribir en disco llegó horas después. Patchstack vio tráfico creciendo hasta multiplicarse por diez en pocas horas. CrowdSec, por su parte, habla de decenas de miles de direcciones IP enviando peticiones compatibles con la vulnerabilidad en cuestión de días (informe CVE-2026-87902). Da igual si tu web es una tienda pequeña o un corporativo: el escaneo es masivo.
Qué hace exactamente el fallo (sin dramatizar de más)
El problema está en get_page_template(): con un parámetro pagename manipulado, se puede forzar la inclusión de un archivo PHP local legible fuera de los directorios del tema activo. Robert Ressl, quien lo reportó por HackerOne, lo resume así en su análisis (ressl.ch): no es un “sube lo que quieras”, es un traversal en la lógica de plantillas que solo se convierte en RCE si se cumplen requisitos concretos.
En la práctica, los atacantes buscan temas con un directorio de primer nivel cuyo nombre empiece por page- (por ejemplo page-templates/) y rutas como pearcmd.php de PEAR cuando PHP tiene register_argc_argv activado. Esa cadena es la que han automatizado los escaneos que documentan Patchstack y medios como webhosting.today. Si tu tema no tiene esa estructura y tu imagen de servidor no deja PEAR accesible, el riesgo baja, pero el core sigue desactualizado y eso no es una estrategia.
Checklist que yo aplico en proyectos reales
1. Versión del core. Confirma 7.1.2 o la versión parcheada de tu rama (7.0.6, 6.9.9, etc.). No te fíes solo del aviso verde del hosting: entra en Escritorio → Actualizaciones o revisa el fichero wp-includes/version.php en staging.
2. Tema activo (padre e hijo). Lista directorios en la raíz del tema. Si existe algo tipo page-assets/ o page-templates/, anótalo: encaja con las precondiciones que describen los informes técnicos. No significa que vayas a ser hackeado mañana, pero sí que eres un objetivo más interesante para el escaneo genérico.
3. PHP en producción. Pide al hosting o mira la config: register_argc_argv=Off en el SAPI que sirve la web. Elimina PEAR y restos de desarrollo en la imagen si no los usas. Son mitigaciones temporales; el parche sigue siendo obligatorio.
4. Logs y WAF. Busca peticiones con pagename codificado, rutas con .. y accesos a pearcmd.php. Si gestionas varios sitios en Plesk o un panel similar, un informe centralizado ahorra horas frente a revisar sitio a sitio.
5. Staging antes de tocar producción. Actualiza primero una copia con el mismo tema y los mismos plugins. CVE-2026-87902 no rompe compatibilidad como otras release recientes, pero un parche de seguridad no te exime de probar checkout o formularios críticos.
Lo que no te cuentan en el titular del CVSS 9.2
La severidad máxima en el advisory choca con la realidad heterogénea de internet: muchos intentos son ruido automatizado que no encuentra las condiciones. Previdian, citado en la prensa especializada, insiste en que la explotación completa es menos probable en configuraciones endurecidas. Yo no traduzco eso en “puedo esperar”: CISA incluyó el CVE en su catálogo de explotación conocida y el plazo para administraciones federales ya pasó. En España, agencias y pymes comparten hosting compartido; un vecino vulnerable no te infecta, pero sí comparte IP y reputación si el servidor se convierte en lanzadera.
Si eres proveedor de mantenimiento, este es el momento de mandar un correo corto al cliente con tres líneas: versión actual, fecha del parche, y si su tema tiene carpetas page-*. No hace falta alarmismo; hace falta trazabilidad. En mi experiencia, el 80% responde cuando entiende que no es “otro update de WordPress”, sino explotación activa documentada.
Después del parche: no cierres el ticket
Actualizar cierra la puerta principal, pero deja preguntas operativas. ¿Tenías copias de seguridad probadas esta semana? ¿Algún plugin de caché te sirve HTML antiguo y oculta que el core ya está en 7.1.2? Monitorizas integridad de ficheros en wp-content/uploads? Un fallo de inclusión de plantillas no debería dejarte shells en uploads, pero los bots que aprovechan ventanas de parche suelen probar varias vías seguidas.
También conviene revisar si algún tema premium te ha colado una estructura page- “porque así venía en el demo”. No es culpa del desarrollador del tema en abstracto; es deuda técnica que ahora pesa más. Renombrar carpetas sin probar puede romper plantillas: hazlo en staging y documenta el cambio.
Para profundizar en condiciones de explotación y mitigaciones, el propio informe de Ressl enlaza un repositorio con laboratorio reproducible; no lo ejecutes en producción, pero sí en staging aislado.
El mensaje que me quedo es simple: el parche salió un martes y el internet empezó a probar tu pagename antes de cenar. En 2026 eso ya es lo normal, y por eso el mantenimiento mensual “cuando hay tiempo” se ha quedado corto.
Si mañana tu hosting te ofreciera bloquear en WAF todas las peticiones con pagename sospechoso pero te cobrara el doble del plan actual, lo activarías sin dudar o preferirías seguir solo con actualizaciones automáticas?