El 22 de septiembre de 2026, víspera del feriado del Día Nacional, WordPress publicó la actualización de seguridad 7.1.2 para cerrar la CVE-2026-87902. La falla no está en un plugin ni en un tema. Está en el núcleo de WordPress y afecta a todas las versiones de la 4.7.0 a la 7.1.1. Ese mismo día, a las 11:49 UTC (2:49 p. m. hora de Riad), la empresa de seguridad Patchstack vio el primer intento de explotarla, y menos de cuatro horas después, el primer intento de escribir un archivo en el servidor de un sitio.

Cómo se propagó el ataque en cinco días

Después se propagó. Según el informe de CrowdSec publicado hoy, 28 de septiembre, su red registró 322.680 señales de ataque que coincidían con la falla desde 30.813 direcciones IP distintas entre el 23 y el 27 de septiembre, con un pico el 27 de septiembre de 124.154 señales. La Autoridad Nacional de Ciberseguridad (NCA) de Arabia Saudita emitió una alerta Crítica, n.º 2026-7873, el 23 de septiembre, y la agencia estadounidense CISA añadió la falla a su catálogo de vulnerabilidades explotadas conocidas el 25 de septiembre.

Qué hace la falla, en términos sencillos

Cuando un visitante solicita una página, WordPress decide qué archivo de plantilla del tema usar para mostrarla. El error está en ese paso: un atacante que no ha iniciado sesión puede dirigirlo a un archivo PHP que está en el servidor fuera de la carpeta del tema, y WordPress lo ejecutará. WordPress califica la falla con 9.2 sobre 10; CISA, con 8.1.

Se convierte en control del sitio cuando coinciden las condiciones señaladas en el aviso de WordPress y en los informes de los investigadores:

  • El tema: el tema activo contiene una carpeta cuyo nombre empieza por page-. El aviso menciona Twenty Twelve, Twenty Fourteen, Neve, Hestia y Sydney entre los temas que la tienen.
  • Un ajuste de PHP: register_argc_argv está activado, lo que según CrowdSec es el valor predeterminado en las imágenes oficiales de Docker de PHP y en los servidores cPanel con PHP anterior a la 8.5.
  • Un archivo auxiliar: el pearcmd.php de PEAR está presente en el servidor. Los atacantes lo usan para escribir nuevos archivos PHP, es decir, una puerta trasera que sobrevive a la actualización.

Así que la falla no afecta a todos los sitios por igual, pero Security Affairs lo resume así: la ejecución de código requiere que la configuración del servidor coincida, y muchos servidores coinciden. El dueño de una empresa normalmente no sabe qué tema está activo ni cómo está configurado el servidor, así que lo prudente es asumir que el sitio está expuesto mientras no se demuestre lo contrario.

Por qué el ataque llegó en horas y no en semanas

Una actualización de seguridad revela por naturaleza dónde está el error, porque el cambio en el código es público. Patchstack afirma que las primeras cargas coincidían exactamente con el patrón que cerró la corrección, lo que significa que quien las escribió trabajó a partir de la propia corrección y no de un descubrimiento independiente. Los primeros intentos solicitaban archivos normales del núcleo de WordPress, como wp-login.php y wp-cron.php, para ver cómo respondían los sitios, y después pasaron a escribir archivos.

El tráfico también lleva las huellas de escáneres automatizados y de código de prueba de concepto publicado. Para el dueño de una empresa, eso significa que nadie está eligiendo su sitio en particular. Las herramientas recorren todos los sitios WordPress a los que pueden llegar, y la diferencia entre un sitio comprometido y uno limpio es si la actualización llegó antes que ellas.

¿Su sitio se actualiza solo?

Probablemente, pero no lo dé por hecho. WordPress tiene actualizaciones automáticas en segundo plano desde la versión 3.7, y desde la 5.6 las instalaciones nuevas actualizan automáticamente tanto las versiones menores como las mayores. El anuncio de la 7.1.2 dice que los sitios que admiten actualizaciones automáticas en segundo plano empezarán a actualizarse automáticamente.

Pero las actualizaciones automáticas pueden desactivarse con una sola línea en wp-config.php. Algunos desarrolladores las desactivan a propósito para que una actualización no rompa un tema personalizado, y algunos proveedores de hosting gestionan las actualizaciones por su cuenta. Un sitio que un freelancer construyó hace años, cuyo contrato ya terminó, puede quedarse en una versión antigua sin que nadie lo note. Para comprobarlo:

  • Inicie sesión en el panel de administración del sitio, abra la página Actualizaciones dentro del menú Escritorio y verá allí la versión actual.
  • La versión segura es la 7.1.2 o posterior. Si su sitio está en una rama anterior, la corrección llegó a todas las ramas hasta la 4.7, incluidas la 7.0.6, la 6.9.9, la 6.8.10 y la 4.7.37; la lista completa está en el aviso de WordPress enlazado en las fuentes.
  • Tenga en cuenta que WordPress dice que solo la versión más reciente recibe soporte activo. Un sitio que se quedó en una rama antigua recibió esta corrección, pero vive de tiempo prestado. Explicamos lo que la nueva versión aporta a un sitio corporativo en WordPress 7.1: las principales novedades.

Elementor también: basta con un enlace

La misma semana, Elementor, el popular constructor de páginas para WordPress, corrigió una falla solo en las versiones 4.3.0 y 4.3.1. Si un administrador del sitio abre un enlace manipulado mientras tiene la sesión iniciada, un atacante puede crear una cuenta de administrador que él controla, y el enlace puede llegar por correo electrónico, chat o un comentario. Según BleepingComputer, esas versiones funcionan en hasta 2 millones de sitios. La corrección se publicó en la 4.3.2 el 24 de septiembre, y el sitio no informó de explotación activa en el momento de su publicación.

Asegúrese de que Elementor esté en la 4.3.2 o posterior, y conviértalo en una norma del equipo: no abrir enlaces de mensajes o comentarios mientras se tiene la sesión iniciada en el panel de administración del sitio.

Si su sitio no se ha actualizado desde el 22 de septiembre

  • Actualícelo ya: si al desarrollador le preocupa que la actualización rompa algo, Patchstack indica que la vía puede cerrarse temporalmente bloqueando los intentos de recorrido de directorios en el parámetro pagename, o desactivando register_argc_argv. Es un trabajo para el hosting o el desarrollador, y no sustituye a la actualización.
  • Asuma que su sitio ha sido sondeado: pida al desarrollador o al hosting que busque archivos PHP que nadie añadió, especialmente en /tmp y /var/tmp, donde Patchstack menciona archivos como poc87902.php y wp-pear-rce-flag.php como señales de una ejecución de código exitosa.
  • Si aparece algo: trátelo como un incidente, no como una actualización. Cambie las contraseñas de las cuentas de administrador, de la base de datos y del hosting, restaure el sitio desde una copia de seguridad limpia y después actualícelo.
  • Si el sitio guarda datos de clientes: si almacena pedidos, formularios de contacto o cuentas, la guía de la Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA) sobre incidentes de violación de datos personales exige que el responsable del tratamiento notifique a la autoridad competente en un plazo de 72 horas desde que tenga conocimiento de una violación que pueda perjudicar los datos o a las personas a las que pertenecen.

La visión de Origami

Muchos sitios web de empresas se construyen sobre WordPress y luego se tratan como un folleto impreso: el desarrollador lo entrega, el dueño paga y nadie pregunta quién lo mantiene actualizado. Esta falla recuerda que un sitio web es un sistema vivo en un servidor expuesto a internet, y que el intervalo entre la publicación de una corrección y la llegada de un atacante ahora se mide en horas. La verdadera pregunta no es si WordPress es seguro, ya que corrigió el error y llevó la corrección a todas las ramas hasta la 4.7. Es quién en su empresa es responsable de instalarla.

Por eso creemos que un contrato de mantenimiento web debe fijar un plazo máximo para instalar las actualizaciones de seguridad críticas, exigir una copia de staging donde las actualizaciones se prueben antes de llegar al sitio en producción, y mantener copias de seguridad periódicas guardadas fuera del propio servidor. Y si las actualizaciones se siguen aplazando porque el tema está personalizado de una forma que se rompe con cada actualización, ese es un problema de cómo se construyó el sitio, no de WordPress, y merece corregirse antes de la próxima falla.

En resumen: tres pasos

  • Hoy: abra el panel de administración y confirme que la versión es la 7.1.2 o la versión corregida de su rama, y que Elementor está en la 4.3.2 o posterior.
  • Esta semana: pida al desarrollador o al hosting que analice el servidor en busca de archivos PHP desconocidos y que confirme por escrito que las actualizaciones automáticas están activadas.
  • Este mes: añada al contrato de mantenimiento un plazo máximo para instalar las actualizaciones de seguridad y nombre a la persona responsable de ello.

Fuentes