Ya explotan la falla crítica de WordPress: si tu sitio no está en 7.1.2, revísalo hoy

El martes 22 de septiembre WordPress publicó la versión 7.1.2 para corregir una sola falla. Para el jueves 24 ya hay ataques reales contra ella. Se llama CVE-2026-87902, tiene 9.2 de 10 de severidad y afecta a todas las versiones de WordPress desde la 4.7, que salió a finales de 2016.

Si tu empresa tiene su página, su blog o su tienda en WordPress, esta es la tarea del día: confirmar en qué versión está.

Qué hace la falla

WordPress decide qué archivo del tema usa para mostrar cada página con una función llamada get_page_template(). Según el aviso de WordPress, un atacante sin cuenta en el sitio puede engañar a esa función para que cargue un archivo PHP de su elección que esté en otra parte del servidor, fuera de las carpetas del tema.

Patchstack, que publicó el análisis técnico, explica que el nombre de la página llega directo de la petición web sin la validación que sí tenían otras partes del código. En la práctica:

• Sin usuario, sin contraseña y sin que nadie de tu equipo haga clic en nada. Basta una petición a tu sitio.
• Para llegar a ejecutar código se necesitan dos condiciones más: que el tema activo tenga una carpeta cuyo nombre empiece con page- (por ejemplo page-templates, algo común en temas comerciales y en algunos temas antiguos de WordPress) y que haya un archivo PHP aprovechable en el servidor. Patchstack señala que ese segundo requisito se cumple con frecuencia en imágenes oficiales de Docker y en hostings con cPanel.

Ya hay ataques

La secuencia fue muy rápida:

El patrón que describen los investigadores es concreto: los atacantes usan un archivo que viene con PHP (pearcmd.php) para escribir un archivo nuevo en /tmp/ y después cargan desde ahí un script para subir más código. Los nombres de archivo que se han visto incluyen wp-pear-rce-flag.php, poc87902.php y archivos que empiezan con luci_ o zeta_ seguidos de caracteres al azar.

Que ya existan herramientas públicas de escaneo cambia el cálculo. Nadie tiene que escoger tu sitio: los bots recorren internet probando todos los WordPress que encuentran. Una PyME de San Luis Potosí con un sitio institucional pesa lo mismo para ellos que una tienda grande.

Por qué le importa a una PyME

El sitio de muchas empresas medianas lo hizo una agencia hace tres o cuatro años, y desde entonces nadie tiene claro quién lo actualiza. Es la misma historia que vimos la semana pasada con la falla 10 de 10 de Magento: la plataforma publica el parche, pero el sitio sigue viejo porque nadie tiene esa tarea asignada.

Un WordPress comprometido no solo se ve mal. Lo que suele pasar después:

• Redirecciones a sitios de estafa o de malware que Google detecta y marca, y tu dominio aparece con advertencia en el buscador.
• Robo de los formularios de contacto o de pedidos, con nombres, correos y teléfonos de tus clientes.
• Uso de tu servidor para mandar spam, con lo que tu dominio termina en listas negras y tus correos legítimos dejan de llegar.
• Si es tienda, desvío de los datos de pago. A siete semanas del Buen Fin 2026, es el peor momento para que pase.

Qué hacer hoy

1. Confirma la versión. Entra al panel, ve a Escritorio > Actualizaciones. Tiene que decir 7.1.2, o la versión corregida de tu rama (7.0.6, 6.9.9, 6.8.10…). Si ves cualquier número menor, actualiza ya.
2. No te fíes de las actualizaciones automáticas. WordPress dice que los sitios que las tienen activas se actualizan solos, pero muchos hostings, temas o plugins las apagan. Revisa el número; no lo supongas.
3. Si no puedes actualizar hoy, revisa si tu tema tiene una carpeta que empiece con page- y pídele a tu hosting que desactive register_argc_argv en PHP. Son medidas temporales, no sustitutos del parche.
4. Busca señales de que ya entraron. Archivos PHP recientes en /tmp y en wp-content, los nombres de archivo de la tabla anterior, usuarios administradores que nadie reconoce y cambios en archivos del tema con fechas de esta semana.
5. Ten un respaldo que puedas restaurar. Si encuentras algo, lo seguro es volver a una copia limpia de antes del 22 de septiembre y actualizar en seguida. Si no tienes respaldos probados, el método está en cómo armar respaldos que sobrevivan un ataque.

El problema de fondo: nadie es dueño del sitio

Hoy tocó WordPress y esta misma mañana fue el séptimo 0-day de Chrome. El ritmo no va a bajar. Lo que sí puedes cambiar es tener a alguien responsable de cada sistema expuesto a internet, con nombre y apellido.

Para el sitio web eso significa tres cosas por escrito: quién lo actualiza, cada cuánto y dónde queda el respaldo. Si lo hace tu agencia, que esté en el contrato con tiempos de respuesta para parches críticos. Si lo hace tu proveedor de TI, lo mismo. Las preguntas para pedírselo están en cómo elegir un proveedor de servicios de TI.

Y una revisión honesta: si tu sitio tiene plugins que nadie usa, un tema que ya no recibe actualizaciones o una versión de PHP vieja, esta falla es solo la más urgente de una lista. Hoy actualizas; la semana que entra conviene limpiar.