Un lector que cuida unas cuarenta instalaciones de clientes me escribió ayer: el nuevo aviso de WordPress lista tantas precondiciones que estuvo tentado de archivarlo bajo un más tarde. Entiendo el instinto. También creo que apunta en la dirección equivocada. Actualiza a 7.1.2 hoy, esa parte lleva minutos. La lección que vale la pena guardar es más grande: este bug solo se volvió peligroso por archivos y flags que la mayoría de nosotros nunca elegimos y jamás hemos auditado ni una sola vez.

; Mitigation while you roll out 7.1.2; updating WordPress is the real fix.
register_argc_argv = Off

La versión seca primero. WordPress 7.1.2 salió el 22 de septiembre de 2026 y cierra CVE-2026-87902, calificado como 9.2 Crítico bajo CVSS 4.0. El fallo está en la resolución de plantillas alrededor de get_page_template(): bajo las condiciones adecuadas, un visitante sin autenticar puede llevar a WordPress a incluir un archivo PHP local fuera del directorio del tema, un CWE-98 de manual. El aviso es GHSA-7hp8-65ch-5whp, y el arreglo se ha portado hacia atrás hasta la rama 4.7, así que hay una release de seguridad esperando para prácticamente cada instalación de la que te avergüenzas.

Ahora la parte interesante, las condiciones. Para que el include malicioso sea alcanzable, el tema activo necesita un directorio de primer nivel cuyo nombre empiece por page-, algo como page-templates. El aviso nombra Twenty Twelve, Twenty Fourteen, Neve, Hestia y Sydney como temas donde ese layout existe, lo cual no es una acusación, solo geografía. Y para convertir una inclusión de archivo en ejecución de código, el atacante necesita un archivo PHP útil ya presente en disco. El ejemplo del aviso es pearcmd.php, que se convierte en un gadget una vez que register_argc_argv está activado, una combinación que señala explícitamente para la imagen oficial de PHP en Docker y para instalaciones cPanel por defecto que corren versiones de PHP por debajo de 8.5.

Vuelve a leer esa lista. Hay un ayudante de línea de comandos de PEAR que viene en la imagen base tecleaste pear o no en esta década. Hay register_argc_argv, un flag de ini heredado de la era CGI. Incluso la condición del tema es solo una costumbre de nombrar directorios más vieja que el editor de bloques. Ninguna de estas cosas es un bug por sí sola. Juntas forman la pista de despegue que permite que un desliz en la resolución de plantillas alce el vuelo hacia la ejecución remota de código. WordPress escribió la línea vulnerable, pero el stack de alrededor puso los cómplices.

El contraargumento justo es que ese apilamiento es exactamente lo que protegió a la mayoría de los sitios. Tres condiciones tienen que alinearse, así que una instalación desactualizada no está automáticamente a una petición bien construida de ser tomada, y el aviso lo dice así. Cierto, y me alegra que la cobertura se mantuviera mayormente calmada al respecto. Aquí está por qué aun así no me relajo: cada una de esas condiciones es barata de sondear de forma remota a escala. La estructura del tema se filtra por las URLs de los assets, las huellas del hosting delatan cPanel, y los atacantes automatizan esas comprobaciones en una tarde mientras los defensores se dicen que los astros probablemente no se alinearán en sus máquinas. Las precondiciones estrechas se leen bien en un aviso y fatal en un informe de incidente.

Así que el orden de las operaciones es aburrido a propósito. Actualiza primero, desde el panel o con la release correspondiente a la rama que corras. Luego, ya que estás en la máquina de todas formas, revisa register_argc_argv y desactívalo salvo que tengas una razón real para mantenerlo, porque eso solo rompe el eslabón de pearcmd.php en la cadena. Y si un sitio estuvo expuesto en una versión afectada con un tema y una configuración de hosting que encajaban, dedica diez minutos a hacer grep en el log de acceso buscando peticiones raras de plantillas y compara wp-content contra una copia sana antes de cerrar el ticket.

El arreglo más largo es tratar tu imagen base como una dependencia. Que el aviso trace una línea en PHP 8.5 es una pista de que los valores por defecto más nuevos de la plataforma ya cierran parte de esta ruta. Si construyes sobre la imagen oficial de Docker, te cuesta dos líneas en la etapa de producción quitar las herramientas de PEAR que nunca invocas. A la gente de Go le gusta señalar que su artefacto de despliegue es un solo binario sin nada más dentro, y vale, se lo ganaron, pero nada impide que un contenedor de PHP sea casi igual de desnudo. Solo tenemos que aceptar que el software que nunca instalamos a propósito sigue contando como superficie de ataque.

Lo que me lleva a la pregunta que de verdad quiero que se responda bajo esta columna. Cuando auditas una máquina o imagen de producción, ¿sales a cazar restos ejecutables como pearcmd.php, o tu revisión se detiene en tu propio código y en composer.lock? Y si la respuesta honesta es la segunda, ¿qué haría falta, herramientas, tiempo o un susto como este, para mover esa línea?