1 Localice cada PHP del servidor

Muchos servidores ejecutan más de un PHP: el paquete del sistema, versiones instaladas por un panel de control (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), contenedores y compilaciones de línea de comandos usadas por cron. Cada uno que atienda solicitudes web debe actualizarse.

Ejecute php -v, liste los procesos php-fpm con ps aux | grep php-fpm y revise el selector de PHP de su panel.

2 Actualice a una versión corregida

Las versiones originales corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los paquetes de las distribuciones pueden incluir la corrección con un número de versión anterior; revise el changelog en busca de CVE-2026-109618 y CVE-2026-109619.

PHP 8.1 y anteriores no reciben ninguna versión del proyecto PHP. Se publicaron backports mínimos del código fuente para 7.4, 8.0 y 8.1 para quienes compilan desde el código fuente, pero la solución duradera es migrar a una rama con soporte.

Debian / Ubuntu (paquetes de la distribución)

Instale la actualización de seguridad de su distribución y reinicie PHP. El número de versión puede seguir siendo el mismo; el changelog del paquete indica el CVE.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Aplique las erratas del proveedor para su flujo de módulo de PHP y reinicie.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / imágenes oficiales de php

Descargue o reconstruya con la etiqueta corregida y vuelva a crear los contenedores.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Use la herramienta de actualización del panel para cada versión de PHP instalada (EA-PHP, gestores PHP de Plesk, alt-php, CustomBuild) y reinicie PHP-FPM. Los paneles suelen mantener versiones antiguas instaladas para sitios concretos; actualícelas o elimínelas también.

Alojamiento compartido o gestionado

Normalmente no puede actualizar PHP usted mismo. Use el mensaje de la tarjeta de resultados para pedir a su proveedor la versión exacta, la fecha del parche y la confirmación de que se reiniciaron los procesos.

Windows / IIS

Descargue la compilación corregida desde windows.php.net, sustituya el directorio de PHP y recicle los grupos de aplicaciones de IIS.

3 Reinicie todos los procesos PHP

Instalar un paquete no cambia el código que ya se está ejecutando. Reinicie PHP-FPM, Apache (para mod_php), LiteSpeed, FrankenPHP, los procesos de colas y los supervisores. En el caso de contenedores, vuelva a construir o descargue la nueva imagen: reiniciar la misma imagen no instala ningún parche.

4 Verifique

Ejecute php -v para cada binario y confirme que los procesos en ejecución usan la nueva compilación (por ejemplo, ls -l /proc/$(pgrep -o php-fpm)/exe no debe indicar «deleted»). Después vuelva a ejecutar este comprobador.

5 Si no puede actualizar hoy

Aplique las mitigaciones parciales que se indican abajo y restrinja quién puede acceder al sitio hasta que pueda actualizar. Reducen el riesgo, pero no lo eliminan.

6 Busque indicios de compromiso y renueve los secretos

Si un sitio vulnerable era accesible desde Internet, revise la actividad a partir del 20 de octubre de 2026: caídas de procesos PHP (SIGSEGV) en el registro de errores de PHP-FPM o Apache, archivos PHP nuevos o modificados en la raíz web, nuevas tareas cron, nuevas cuentas de administrador y conexiones salientes inesperadas.

Como CVE-2026-109619 puede exponer la memoria del proceso PHP sin ejecutar ningún código, un sistema de archivos limpio no demuestra que no se haya filtrado nada. Cambie las contraseñas de bases de datos, las claves de API y las credenciales de pago y de correo, e invalide las sesiones de usuario de los sitios que estuvieron expuestos.

7 Después de actualizar

La corrección introduce un nuevo límite estricto de memoria: un proceso que lo alcanza se termina de inmediato y los manejadores de cierre no se ejecutan. Compruebe cómo se comporta su aplicación bajo presión de memoria, revise memory_limit junto con post_max_size y max_input_nesting_level, y deshaga cualquier memory_limit = -1 temporal que haya configurado antes de aplicar el parche. Ocultar la versión con expose_php = Off es un refuerzo opcional, no una corrección.

Mitigaciones parciales (de php.net y los avisos)

Solo reducen las vías de ataque conocidas. php.net afirma que actualizar es la única opción segura.

; php.ini / FPM pool (php_admin_value) — reinicie todos los procesos después
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M si se necesitan subidas de archivos
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Configúrelas en php.ini, en el pool de PHP-FPM (php_admin_value) o en la configuración del servidor, no con ini_set() ni .user.ini, y reinicie los procesos. Otras medidas de los avisos y del equipo de investigación:

memory_limit = -1 bloquea algunas vías que dependen del propio límite de memoria de PHP, pero deja el agotamiento de memoria en manos del sistema operativo: úselo solo junto con un límite cgroup v2 memory.max. No use RLIMIT_AS ni RLIMIT_DATA; pueden activar las mismas vías vulnerables.
Reduzca max_input_nesting_level tanto como lo permitan sus formularios.
Reduzca pm.max_requests de PHP-FPM para que los procesos se reciclen con más frecuencia (con coste de rendimiento).
Límites de tamaño de solicitud, de número de campos y de anidamiento en el servidor web o el proxy; elimine los ajustes INI por solicitud no válidos u obsoletos.
Las políticas de SELinux o AppArmor pueden limitar lo que puede ejecutar un proceso comprometido: reducen el impacto, pero no impiden la divulgación de memoria.

Referencias

Fuente: aviso de seguridad de php.net, 21 de octubre de 2026. Última verificación: 2026-10-23.