---
title: "Fallos críticos en PHP: qué suponen para WordPress y qué hacer hoy"
description: "PHP corrige hoy a las 16:00 dos vulnerabilidades críticas. Actualizar WordPress no basta: hay que actualizar PHP en el servidor. Cómo comprobar la versión y qué medidas tomar."
url: https://wpdirecto.com/fallos-criticos-php-wordpress-que-hacer/
date: 2026-10-21
modified: 2026-10-21
author: "Editor WPDirecto"
image: https://wpdirecto.com/wp-content/uploads/2026/10/extract-php-critical-flaw.jpg
categories: ["Seguridad", "Actualidad"]
tags: ["actualizaciones", "hosting", "php", "PHP 8", "seguridad", "servidores", "vulnerabilidad", "woocommerce", "wordpress"]
type: post
lang: es
---

# Fallos críticos en PHP: qué suponen para WordPress y qué hacer hoy

**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**

- PHP corrige hoy a las 16:00 dos fallos críticos con CVSS 9,2.
- El fallo está en PHP, no en WordPress: actualizar el núcleo, los temas o los plugins no protege.
- La corrección depende del proveedor de alojamiento o de quien administre el servidor.
- Solo PHP 8.2, 8.3, 8.4 y 8.5 reciben parches; WordPress recomienda PHP 8.3 o superior.
- Desactivar el progreso de subidas de sesión es una medida temporal que no garantiza protección.

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](https://www.opensecurity.es/php-vulnerabilidades-criticas-filtradas-actualizacion-21-octubre/) y en qué no coinciden las distintas fuentes.

## Por qué afecta a cualquier WordPress

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](https://wpdirecto.com/como-revisar-tus-webs-wordpress-tras-un-ataque-como-el-de-rank-math-pro/), donde el problema estaba en un plugin y se resolvía dentro de WordPress.

## Cómo saber qué versión de PHP usa 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.

## Qué hacer hoy en los sitios WordPress

- Hacer inventario de los sitios y su versión de PHP, incluidas webs de pruebas y entornos de desarrollo expuestos.
- En alojamiento compartido o gestionado, preguntar al proveedor cuándo aplicará la actualización. La mayoría de usuarios no puede hacerlo por su cuenta.
- En servidores propios o VPS, preparar la actualización de los paquetes de PHP desde los repositorios de la distribución o del proveedor de paquetes que se use, y reiniciar php-fpm o el servidor web después.
- Tener una copia de seguridad reciente de archivos y base de datos antes de tocar nada.
- Tras actualizar, comprobar en Salud del sitio que la versión de PHP ha cambiado y revisar que la web, los formularios y el proceso de compra funcionan.

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.

## Cómo mitigar el riesgo con Cloudflare en WordPress

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:

- Comprobar que el Cloudflare Managed Ruleset está activado: en el panel, en **Security > Settings**, filtrar por «Web application exploits» y activar «Cloudflare managed ruleset». Solo está disponible en los planes Pro, Business y Enterprise; el plan gratuito incluye el Free Managed Ruleset, que la nota de Cloudflare no menciona.
- Revisar las cuatro reglas «Anomalous Execution» desde **Security rules**, en la regla del conjunto gestionado, con la opción «Browse rules», y valorar pasar a bloqueo las dos que solo registran, después de comprobar en los eventos de seguridad que no rompen el panel de administración, los formularios ni la subida de medios.
- Vigilar los eventos de seguridad para ver si estas reglas saltan sobre el sitio.
- Asegurarse de que el servidor de origen solo acepta tráfico de las IP de Cloudflare, porque el WAF no protege las peticiones que llegan directamente a la IP del alojamiento.

Como el resto de medidas temporales, no sustituye a la actualización de PHP.

## Preguntas frecuentes

### ¿Las vulnerabilidades de PHP afectan a WordPress?

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.

### ¿Actualizar WordPress protege de estos fallos?

No. Hay que actualizar PHP en el servidor. En alojamientos compartidos o gestionados, eso lo hace el proveedor.

### ¿Cómo sé qué versión de PHP usa mi WordPress?

En Herramientas, Salud del sitio, Información, Servidor. También con el comando wp –info de WP-CLI.

### ¿Sirve desactivar session.upload_progress en WordPress?

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:

- [OpenSecurity: PHP corrige hoy dos fallos críticos que se filtraron antes del parche](https://www.opensecurity.es/php-vulnerabilidades-criticas-filtradas-actualizacion-21-octubre/)
- [PHP: Upcoming Critical PHP Security Release](https://www.php.net/archive/2026.php#2026-10-20-1)
- [CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP](https://cert.europa.eu/publications/security-advisories/2026-018/pdf)
- [GMO Flatt Security: análisis de php2shell](https://blog.flatt.tech/entry/php2shell)
- [Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619](https://sansec.io/research/php2shell)
- [Cloudflare: WAF Release 2026-10-21, Emergency, Cloudflare Managed Ruleset](https://developers.cloudflare.com/changelog/post/2026-10-21-emergency-waf-release-cfmr/)
- [WordPress.org: requisitos de WordPress](https://wordpress.org/about/requirements/)
