El equipo de PHP ha publicado el 21 de octubre de 2026 una actualización para dos vulnerabilidades críticas, con una gravedad de 9,2 sobre 10, que permiten ejecutar código en el servidor sin necesidad de iniciar sesión. Afecta a cualquier web hecha con PHP, WordPress incluido, y se arregla actualizando PHP en el servidor: las versiones corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
Lo que nos encontramos esta mañana
Esta mañana hemos revisado los servidores de todas las webs que mantenemos. Tres funcionan en servidores propios con PHP 8.3 y el resto en alojamientos compartidos, donde la versión de PHP la decide el proveedor. Todas son WordPress, y WordPress funciona con PHP: si el lenguaje tiene un fallo, lo tiene la web, por muy al día que estén los plugins.
El aviso oficial está en php.net: dos fallos críticos (CVE-2026-109618 y CVE-2026-109619), puntuados con 9,2 en la escala CVSS 4.0, que permiten a un atacante ejecutar código en el servidor con una simple petición a la web. Están en riesgo todas las instalaciones de PHP que sirven páginas, con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed, y el propio equipo de PHP considera más expuesto mod_php. Según su aviso, no hay ninguna medida que lo frene del todo: actualizar es la única opción segura.
Esa misma tarde actualizamos PHP en los tres servidores propios y comprobamos que todas sus webs seguían respondiendo.
Lo que no es
No es un fallo de WordPress ni de un plugin, así que no se arregla desde el escritorio de WordPress. Actualizar el núcleo, el tema y los plugins sigue siendo necesario, pero esta vez el parche va en el servidor. Un plugin de seguridad tampoco lo sustituye: ayuda a frenar ataques conocidos, pero no corrige un fallo del lenguaje sobre el que funciona la propia web.
¿A quién le afecta y quién tiene que actualizar?
- Webs en servidor propio (VPS o dedicado). El parche lo aplica quien administra el servidor. En Ubuntu o Debian se instala actualizando los paquetes de PHP cuando el sistema los publica, normalmente unas horas después de la versión oficial.
- Webs en alojamiento compartido. Lo actualiza el proveedor del hosting en sus servidores. Lo que está en tu mano es comprobar que lo ha hecho y elegir en el panel la versión de PHP más reciente.
- Webs en PHP 7 o anterior. Son las más expuestas, porque esas versiones ya no reciben parches. La única salida es pasar a una versión con soporte, PHP 8.2 o superior.
Cómo comprobarlo en cinco minutos
- En el escritorio de WordPress, entra en Herramientas, Salud del sitio, pestaña Información, apartado Servidor. Ahí aparece la versión de PHP.
- Si empieza por 5 o por 7, pide hoy mismo a tu proveedor el cambio a PHP 8. Haz antes una copia de seguridad y revisa la web después, porque algún plugin antiguo puede dejar de funcionar.
- Si es PHP 8 en un alojamiento compartido, apunta la versión exacta y compárala con las versiones corregidas: 8.2.35, 8.3.36, 8.4.27 o 8.5.12, según la rama. Si en uno o dos días no ha cambiado, escribe al soporte del hosting.
- Si la web está en un servidor propio con Ubuntu o Debian, no te fíes del número: el parche se aplica sobre la misma versión y PHP 8.3.6 sigue diciendo 8.3.6. Lo que hay que mirar es que el paquete de PHP se haya actualizado (en Ubuntu 24.04, el paquete corregido es el 8.3.6-0ubuntu0.24.04.13) y que después se haya reiniciado PHP-FPM o el servidor web.
Lo que aprendimos
Que mantener una web no es solo actualizar plugins. En junio escribíamos sobre cuatro plugins de WordPress en riesgo grave, y aquel parche se instalaba con un clic. Este no aparece en el escritorio de WordPress: hay que saber dónde está alojada la web, qué versión de PHP usa y quién puede cambiarla.
Es la parte del mantenimiento web que menos se ve y la que más pesa en días como hoy. Si no tienes a mano esas tres respuestas, averígualas hoy, antes de que los ataques automáticos empiecen a buscar servidores sin actualizar.
Actualización del 6 de noviembre: si tu web es WordPress, revisa también cómo actualizar WordPress a 7.1.4, porque ya hay ataques en marcha.
