Parche de emergencia de PHP para dos fallos críticos

PHP publicó este miércoles un parche de emergencia de PHP para todas sus ramas con soporte: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen dos fallos críticos, con una puntuación de 9.2 sobre 10, que permiten ejecutar código en el servidor sin autenticarse. El equipo de PHP pide actualizar de inmediato y avisa de que no hay ninguna medida que proteja del todo: «actualizar es la única opción segura».

El aviso llegó con un día de antelación. El martes, el equipo de seguridad de PHP anunció una versión de seguridad para el 21 de octubre a las 14:00 UTC, sin dar detalles, y se reservó el derecho de adelantarla si los fallos se hacían públicos o si aparecían ataques reales. Antes de que saliera, la empresa de seguridad watchTowr ya decía haber reproducido uno de ellos, y su director, Benjamin Harris, aseguró a la prensa que eran reales y que afectaban a versiones de PHP hasta la 5. El parche salió a su hora, junto con dos avisos técnicos en GitHub.

PHP es el lenguaje con el que funcionan WordPress, Drupal, Laravel, Moodle y buena parte de los servidores web del mundo. Por eso un fallo que se puede explotar con una simple petición HTTP, sin usuario ni contraseña, es de lo más grave que le puede pasar.

Claves del parche de emergencia de PHP

Dos fallos, CVE-2026-109618 y CVE-2026-109619: los dos tienen gravedad crítica (CVSS 4.0 de 9.2) y permiten ejecución remota de código sin autenticar. Afectan a todas las versiones anteriores a las publicadas hoy.
El primero, al quedarse sin memoria: cuando una petición agota la memoria, PHP la aborta de golpe. Si eso ocurre justo cuando los datos internos de la petición están a medio preparar, el cierre de la petición los trata después como válidos. Un atacante puede provocarlo con formularios de subida de archivos manipulados, por ejemplo con miles de cabeceras en una sola parte, sin pasar los límites aparentes de PHP.
El segundo, con memoria ya liberada: parte del estado interno de PHP sobrevive a una petición y sigue apuntando a memoria que ya se liberó. Si el mismo proceso atiende otra petición y la usa antes de reiniciarla, el atacante puede aprovecharlo. El ataque demostrado usa dos peticiones distintas que caen en el mismo proceso.
Quién está en riesgo: toda instalación de PHP que sirva páginas web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor con mod_php, donde hay un ataque demostrado que se dispara antes de que se ejecute una sola línea de la aplicación. En FPM, el análisis del código indica que también es vulnerable, aunque no se ha demostrado un ataque completo.
Versiones antiguas: PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto. Aun así, por la gravedad, el equipo de PHP ha dejado parches mínimos de código fuente para 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta. Las distribuciones y los proveedores de soporte extendido recibieron los parches por adelantado.
PHP 8.2 tiene fecha de caducidad: el anuncio de la 8.2.35 recuerda que esa rama deja de recibir parches de seguridad el 31 de diciembre de 2026.

Qué hacer si tienes un sitio en PHP

Lo primero es saber qué versión usa el servidor. En la línea de órdenes basta con php -v, pero ojo: el PHP de la consola puede no ser el mismo que sirve la web. Lo seguro es mirarlo desde el propio sitio (en WordPress, en Herramientas → Salud del sitio → Información → Servidor) o preguntar al proveedor de alojamiento.

Si tu servidor es tuyo: actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 con los paquetes de tu distribución o desde php.net, y reinicia PHP-FPM o Apache para que los procesos carguen la versión nueva.
Si usas contenedores: reconstruye las imágenes cuando haya versión corregida. La imagen oficial php:8.5-cli de Docker Hub tardó unas tres horas en pasar a la 8.5.12 (lo hizo hacia las 16:55 UTC del 21 de octubre): comprueba que tu imagen base ya no es la 8.5.11.
Si tienes un alojamiento compartido: la actualización depende del proveedor. Conviene comprobar que la aplica y, si el panel deja elegir la versión de PHP, no quedarse en una rama sin soporte.
Si no puedes actualizar todavía: el aviso oficial propone medidas que reducen algunos caminos de ataque, pero insiste en que no hacen segura una instalación. Entre ellas: desactivar session.upload_progress.enabled en php.ini o en el pool de FPM y reiniciar todos los procesos; bajar post_max_size a 8 MB si no hay subidas de archivos; y limitar en el servidor web o el proxy el tamaño de las peticiones, sus campos y sus cabeceras. Ponerlas con ini_set() o en un .user.ini no sirve, porque el ataque ocurre antes, y ocultar los errores tampoco ayuda.

Los avisos técnicos se publicaron con todos los detalles a la vez que el parche, así que es cuestión de tiempo que aparezcan ataques automatizados. Para quien mantiene un sitio en WordPress o en cualquier otra aplicación PHP, la prioridad de hoy es comprobar la versión y actualizar.

Más fuentes: avisos técnicos GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp en GitHub, aviso previo de PHP y IT-Connect (declaraciones de watchTowr). Portada: un elePHPant, la mascota de PHP, foto de Atomic Taco, licencia CC BY-SA 2.0, Wikimedia Commons.

Fuente: PHP, «Security advisory: Critical remote code execution vulnerabilities, update now», 21 de octubre de 2026