El proyecto PHP publicó actualizaciones de seguridad urgentes el 21 de octubre de 2026. Las correcciones cubren CVE-2026–109618 y CVE-2026–109619, ambas con una puntuación de 9,2 sobre 10 en CVSS v4.0. El primer fallo permite ejecutar código mediante una corrupción causada por falta de memoria. El segundo se relaciona con un estado obsoleto de los procesos worker.

Las vulnerabilidades están en PHP, no en WordPress Core, los plugins ni los temas. Actualizar WordPress no actualiza el servicio PHP que atiende el sitio. Un atacante sin autenticación que consiga explotarlas puede obtener el mismo acceso que la web. Eso puede permitirle leer credenciales y datos, modificar archivos o instalar una puerta trasera persistente.

PHP confirmó la ejecución remota de código en los dos casos. También confirmó una vía de ataque para CVE-2026–109618 que puede ejecutarse antes de que arranque WordPress. CrowdStrike afirma que su exploit privado funcionó de forma fiable en sistemas Intel, AMD y Arm, incluso contra procesos PHP recién reiniciados. Wordfence no probó de forma independiente ese exploit no publicado. El ataque puede requerir ajustes para un servidor concreto, pero un servidor sin parchear no debe considerarse seguro. Ya circulan pruebas de concepto públicas, algunas incompletas o incorrectas.

El equipo de Wordfence Threat Intelligence comenzó las pruebas pocas horas después de la publicación de los parches. En un laboratorio Apache configurado específicamente con PHP 8.5.11, una prueba de concepto de CVE-2026–109619 enviada por HTTP creó un archivo de texto temporal. El resultado confirmó la ejecución de código en ese entorno. La misma prueba provocó el cierre de una compilación optimizada normal de PHP 8.5.11, mientras PHP 8.5.12 siguió funcionando. Para CVE-2026–109618, PHP 8.5.11 falló al procesar la petición de prueba y PHP 8.5.12 la gestionó con normalidad. En otras pruebas, WordPress 7.1.3 junto con un paquete vulnerable de Ubuntu que incluía PHP 8.5.4 sufrió fallos o reinicios en algunas configuraciones. Wordfence no logró ejecutar código de forma independiente para esta CVE. La investigación continúa porque el comportamiento cambia según el servidor.

Las primeras versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones de Linux y los proveedores de soporte a largo plazo pueden incorporar las correcciones en paquetes cuyo número principal de versión sea anterior. Por eso hay que comprobar la revisión completa del paquete y el aviso de seguridad del proveedor. El proyecto PHP ya no publica versiones para PHP 8.1 ni para ramas anteriores. Los usuarios de esas ramas deben obtener una confirmación explícita del proveedor o migrar a una rama compatible.

Los clientes de hosting gestionado deben preguntar si el servicio PHP que atiende su sitio incluye ambas correcciones y si se ha reiniciado PHP. Quienes administran sus propios servidores deben actualizar PHP y reiniciar Apache, PHP-FPM u otro servicio PHP. Los contenedores tienen que reconstruirse y desplegarse desde una imagen actualizada. Las agencias y los proveedores de hosting deben revisar los entornos de producción, pruebas y origen, además de los contenedores antiguos.

La versión PHP utilizada por el sitio se puede consultar en WordPress, en Tools > Site Health > Info > Server. El resultado de `php -v` en la línea de comandos puede corresponder a otra instalación de PHP. Después de actualizar, hay que verificar la versión que usa realmente el sitio y la revisión completa del paquete. Conviene conservar las copias de seguridad y los registros del servidor web, PHP, el firewall y el sistema desde al menos las 48 horas anteriores al 21 de octubre hasta la instalación y el reinicio. Si el parche se retrasó, hay que buscar actividad inusual. La ausencia de indicios claros no demuestra que no haya habido una intrusión.

Las recomendaciones temporales de PHP pueden reducir la exposición a determinadas vías de ataque si no es posible parchear de inmediato. Son incompletas, pueden alterar funciones normales y no sustituyen la actualización. El firewall de Wordfence protege la capa de aplicación de WordPress. Estos fallos afectan a PHP en el servidor y algunos ataques pueden comenzar antes de que se cargue WordPress. Por ello, PHP, el servidor web, el sistema operativo y el perímetro de red necesitan sus propias actualizaciones y controles.