PHP: dos vulnerabilidades críticas de ejecución remota de código

El problema

El 21 de octubre de 2026, el proyecto PHP publicó dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación:

Están corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Todas las versiones anteriores de esas ramas son vulnerables.

Quién está en riesgo

Según el anuncio, toda instalación de PHP que sirva peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

El riesgo más alto es el de Apache con mod_php. Hay un ataque demostrado en el que una petición sin autenticar provoca el fallo antes de que se ejecute el código de la aplicación. Da igual lo bien escrita que esté tu aplicación.

Qué son, sin entrar en el exploit

CVE-2026-109618 (falta de memoria). Cuando PHP se queda sin memoria (out of memory), corta la petición en seco. Si eso ocurre en un momento en que los datos internos de la petición están a medio inicializar, la limpieza posterior los trata como válidos. Según el aviso, hay varias formas de agotar la memoria con una petición multipart que, en apariencia, respeta los límites de PHP. En mod_php todo ocurre durante el arranque de la petición; en FPM el análisis del código apunta a que también es vulnerable, aunque no se ha demostrado un exploit completo.

CVE-2026-109619 (estado de una petición anterior). Un proceso de PHP atiende muchas peticiones seguidas. Algunos datos internos que pertenecen a una petición pueden sobrevivir cuando ya se ha liberado su memoria. Si la siguiente petición que atiende el mismo proceso los usa antes de reiniciarlos, se produce un use after free. El aviso describe el ataque en dos peticiones: una deja el estado colgando, por ejemplo con un error fatal o un timeout, y la siguiente lo consume.

La solución: actualizar

Es la única solución completa. Los dos avisos lo dicen así.

1. Comprueba qué versión tienes. La de la web, no solo la de la consola: pueden ser binarios distintos. php -v php-fpm -v # el nombre del binario varía: php-fpm8.3, php83-fpm... Una página temporal con <?php phpinfo(); muestra la versión que de verdad sirve las peticiones. Bórrala en cuanto la hayas visto.
2. Actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Según el anuncio:
   • Si usas los paquetes de tu distribución, usa sus actualizaciones: las distribuciones y los proveedores LTS recibieron los parches por adelantado.
   • Los fuentes y los binarios de Windows están en la página de descargas de php.net.
3. Reinicia todos los procesos de PHP (el servicio de FPM, o Apache si usas mod_php). Un proceso que sigue corriendo mantiene la versión vieja cargada.

¿PHP 8.1 o anterior? El proyecto ya no publica versiones para esas ramas. Por la gravedad, el equipo de seguridad ha preparado parches mínimos para PHP 7.4, 8.0 y 8.1, para quien compila desde fuentes. Si tu PHP viene de una distribución o de un proveedor LTS, pregúntales si incluyen el parche, o pasa a una versión soportada.

Si hoy no puedes actualizar

Estas medidas reducen la exposición a vías de ataque concretas, pero no hacen segura la instalación. Son para ganar tiempo, no para quedarse así.

Contra CVE-2026-109618:

• memory_limit=-1, fijado de forma que la aplicación no pueda cambiarlo. Elimina el límite de memoria por petición que usa el ataque confirmado. Comprueba que ningún pool, directorio o configuración de la aplicación vuelva a poner un límite. El aviso advierte que no es una solución completa: si falla una reserva de memoria del propio sistema, se puede llegar igual al código vulnerable. ; pool de PHP-FPM php_admin_value[memory_limit] = -1 # Apache con mod_php php_admin_value memory_limit -1
• Un post_max_size bajo: 8M si la aplicación no sube ficheros, 32M si los sube. Mantén upload_max_filesize por debajo de post_max_size.
• Límites en el servidor web o en el proxy: tamaño de la petición ya decodificada, número de campos, partes multipart, cabeceras y profundidad de anidamiento. Tienen que cubrir también las peticiones sin un Content-Length usable.
• Un límite de contenedor o de cgroup como frontera de disponibilidad, preferiblemente uno que mate solo al proceso afectado. No uses RLIMIT_AS ni RLIMIT_DATA en su lugar, porque pueden provocar justo el fallo de memoria vulnerable.

Contra CVE-2026-109619:

• session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la configuración del servidor, y reinicia todos los procesos. No sirve ponerlo con ini_set() ni en un .user.ini de FPM. Bloquea las vías confirmadas a través de sesiones, pero no otras variantes.
• En PHP 8.5, fatal_error_backtraces=0, y reinicia. Solo bloquea la vía confirmada de los backtraces fatales.
• Quita los ajustes inválidos u obsoletos que se aplican en cada petición y generan avisos antes de la inicialización. Ocultar los avisos con error_reporting, display_errors o @ no ayuda.
• Corrige los errores fatales y los timeouts que un atacante pueda provocar, también en callbacks, en el procesado de subidas o importaciones y en la limpieza.

Conclusión

Son dos fallos críticos que se pueden explotar sin autenticación, en el caso de mod_php antes de que llegue a ejecutarse tu código. Actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, reinicia todos los procesos de PHP y comprueba la versión que sirve la web. Las mitigaciones solo sirven para ganar tiempo.

Fuentes

• Aviso GHSA-w8hw-w9fx-j79w (CVE-2026-109618), RCE via OOM corruption: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• Aviso GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), RCE via stale global state: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• Anuncio del proyecto PHP del 21-10-2026, Security advisory: Critical remote code execution vulnerabilities, update now.