PHP publicará hoy, miércoles 21/10/2026, a las 16:00 (hora peninsular) una actualización para dos vulnerabilidades críticas, con una puntuación de 9,2 sobre 10 en CVSS v4.0, y todas las webs WordPress funcionan sobre PHP. Los detalles técnicos y las versiones afectadas no se conocerán hasta esa hora, pero varios investigadores apuntan a fallos de ejecución remota de código y GMO Flatt Security asegura haber reproducido el ataque en instalaciones de WordPress. Para quien gestiona sitios WordPress o tiendas WooCommerce, la clave está en que esta vez el parche no llega por el panel de WordPress: hay que actualizar PHP en el servidor.
Las claves de las vulnerabilidades de PHP para WordPress en 30 segundos
El aviso oficial de PHP solo confirma que son dos fallos críticos y la hora de publicación. Los identificadores que circulan, CVE-2026-109618 y CVE-2026-109619, proceden de la filtración que adelantó la noticia el 20/10/2026, y la información disponible hasta ahora sale de investigadores, no de PHP. En opensecurity.es se recoge todo lo que se sabe de estas vulnerabilidades críticas de PHP y en qué no coinciden las distintas fuentes.
WordPress es una aplicación escrita en PHP: cada vez que alguien visita una página, envía un formulario o sube una imagen, es el intérprete de PHP del servidor el que ejecuta el código. Si el fallo está en el propio PHP, como indican los investigadores, el riesgo no depende de tener un tema o un plugin vulnerable. Una instalación limpia y al día puede estar expuesta igual que una abandonada.
Según GMO Flatt Security, el ataque se ha reproducido en entornos con mod_php y php-fpm, y en aplicaciones como WordPress, Laravel y Symfony, que la empresa presenta como ejemplos y no como lista cerrada. Sansec, especializada en comercio electrónico, sostiene que afecta a todos los servidores con PHP 5.4 o posterior, incluidas las tiendas WooCommerce, y que solo se puede corregir en la infraestructura, no desde el código de la tienda. Nada de esto está confirmado todavía por PHP.
El matiz práctico es importante. Las actualizaciones automáticas de WordPress cubren el núcleo y, si se activan, plugins y temas, pero no tocan la versión de PHP del servidor. Un sitio con todo en verde en el escritorio puede seguir ejecutando un PHP vulnerable. Es una situación distinta a la de incidentes recientes como el del malware en Rank Math PRO, donde el problema estaba en un plugin y se resolvía dentro de WordPress.
Lo primero es saber qué PHP tiene cada sitio. WordPress lo muestra en Herramientas > Salud del sitio > Información > Servidor. Quien gestione varios sitios por línea de comandos puede usar WP-CLI:
wp --info
wp eval "echo PHP_VERSION;"Lenguaje del código: JavaScript (javascript)PHP solo publica parches de seguridad para las ramas 8.2, 8.3, 8.4 y 8.5. WordPress, por su parte, recomienda PHP 8.3 o superior y recuerda en su página de requisitos que las versiones antiguas que todavía puede ejecutar, desde PHP 7.4, han llegado al final de su vida útil y pueden exponer el sitio a vulnerabilidades. Si una web sigue en PHP 7.4, 8.0 u 8.1 y los fallos también afectan a esas ramas, no habrá corrección oficial: la única salida será migrar a una versión soportada, probando antes que temas y plugins son compatibles.
Como medida provisional, GMO Flatt Security propone desactivar el seguimiento del progreso de subidas de las sesiones de PHP con session.upload_progress.enabled=0. La empresa advierte de que no puede asegurar que eso detenga el ataque por completo, y otros investigadores creen que uno de los dos fallos está en el procesamiento de formularios con archivos adjuntos, que esta opción no cubriría. Según el tipo de servidor, se aplica en el php.ini, en un archivo .user.ini en la raíz del sitio cuando PHP funciona con php-fpm o CGI, o en el .htaccess cuando se usa mod_php:
; php.ini o .user.ini
session.upload_progress.enabled = 0
# .htaccess (solo con mod_php)
php_flag session.upload_progress.enabled offLenguaje del código: PHP (php)El núcleo de WordPress no usa las sesiones de PHP, así que en una instalación estándar el cambio no debería notarse, aunque conviene probarlo si algún plugin muestra barras de progreso de subida. En cualquier caso, no sustituye a la actualización. El CERT-EU recomienda además, si no se puede parchear de inmediato, valorar aislar de Internet las aplicaciones expuestas hasta poder hacerlo.
A primera hora de hoy no había constancia pública de ataques reales, pero los investigadores esperan intentos de explotación poco después de que salga la corrección, cuando los atacantes puedan comparar el código nuevo con el anterior. Las primeras horas tras las 16:00 serán las más delicadas.
Cloudflare publicó el 21/10/2026 una actualización de emergencia de su Cloudflare Managed Ruleset, el conjunto de reglas gestionadas de su cortafuegos de aplicaciones web (WAF), con cuatro reglas nuevas llamadas «Generic Rules – Anomalous Execution» (de la 1 a la 4) para detectar patrones de peticiones anómalos. La 1 y la 3 bloquean por defecto; la 2 y la 4 solo registran. La compañía no vincula estas reglas a las vulnerabilidades de PHP ni explica qué detectan, así que no hay confirmación de que cubran este caso. Aun así, para un WordPress que ya pasa por Cloudflare es una capa extra mientras llega o se aplica el parche:
Como el resto de medidas temporales, no sustituye a la actualización de PHP.
Afectan al intérprete de PHP sobre el que funciona WordPress, por lo que cualquier sitio puede estar expuesto si su versión de PHP es vulnerable, aunque WordPress, temas y plugins estén actualizados. PHP confirmará hoy las versiones afectadas.
No. Hay que actualizar PHP en el servidor. En alojamientos compartidos o gestionados, eso lo hace el proveedor.
En Herramientas, Salud del sitio, Información, Servidor. También con el comando wp –info de WP-CLI.
Es una medida temporal propuesta por Flatt Security sin garantía de protección total. El núcleo de WordPress no usa sesiones de PHP, así que no debería romper una instalación estándar, pero no sustituye al parche.
Fuentes:
