Parches de PHP: actualiza el motor y verifica el runtime web

Actualizar PHP no termina cuando una terminal muestra un número nuevo. Una máquina puede tener un CLI parcheado y, al mismo tiempo, un pool FPM, un módulo de Apache o una imagen de contenedor sirviendo peticiones con otra compilación. La primera pregunta útil es doble: ¿qué parches corrigen los dos avisos críticos? y ¿qué proceso atiende realmente el tráfico?

Dos CVE corregidos y un aviso separado

El aviso de PHP del 21 de octubre de 2026 identifica dos vulnerabilidades críticas de ejecución remota no autenticada: CVE-2026-109618, relacionada con corrupción por OOM, y CVE-2026-109619, relacionada con estado global obsoleto entre solicitudes. La tabla de ramas corregidas es:

Rama	Versión upstream corregida	Situación
PHP 8.5	8.5.12	Release estable de seguridad
PHP 8.4	8.4.27	Release estable de seguridad
PHP 8.3	8.3.36	Release estable de seguridad
PHP 8.2	8.2.35	Release estable; EOL anunciado para el 31-12-2026

PHP indica que actualizar es la solución completa para esos dos CVE. PHP 8.1 y anteriores ya no reciben correcciones del proyecto, aunque una distribución o proveedor LTS puede publicar un backport: en ese caso hay que conservar la evidencia del proveedor y no inferirla solo por el número upstream. Tampoco conviertas PHP 8.6.0 RC4 en destino de producción; es una versión de prueba.

El aviso informativo del 23 de octubre trata otro escenario: la configuración inicial de session.serialize_handler es php_binary o php_serialize, la aplicación la cambia mediante ini_set() a php antes de session_start() y el seguimiento de progreso de subidas continúa habilitado. PHP recomienda mantener temporalmente session.upload_progress.enabled=0 hasta la siguiente release regular y anuncia que el aviso completo de CVE-2026-115560 acompañará a esa release. Al consultar las fuentes el 24 de octubre no aparece una release estable posterior que cierre ese tercer vector.

Desactivar el progreso no desactiva las subidas multipart normales; sí elimina la función que escribe su avance en la sesión. Si el producto muestra una barra de progreso, prueba su impacto y decide cómo sustituirla. La mitigación temporal tampoco reemplaza los parches de los dos primeros CVE.

La versión de CLI no es la versión del frontend

Estas órdenes son un inventario local y no una auditoría de un servidor:

php -v
php --ini
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'

El resultado describe el ejecutable CLI que invocaste. Para el tráfico web, identifica el SAPI y el artefacto que realmente corre:

• PHP-FPM: revisa el paquete o la imagen del pool y la configuración efectiva del pool; recarga o reinicia todos los workers según el procedimiento de tu distribución.
• Apache con mod_php: comprueba el módulo cargado por el servidor y su configuración; reinicia el servicio web con el mecanismo de tu plataforma.
• CGI, FrankenPHP o LiteSpeed: verifica el binario y la configuración del proceso que recibe las peticiones, no solo el PHP instalado para administración.
• Contenedores: revisa el digest o identificador de la imagen que ejecuta el frontend y actualiza cada réplica; cambiar la imagen local no cambia los workers ya iniciados.

No hay una orden universal de reinicio: el servicio, supervisor u orquestador manda. Guarda en el registro de despliegue la versión, el SAPI, la ruta efectiva de configuración y el identificador de imagen. Una ruta diagnóstica privada y temporal puede servir para una comprobación controlada; no publiques phpinfo() ni expongas la configuración del runtime.

Aplicar la mitigación en la configuración efectiva

Para php.ini o una configuración equivalente de servidor, la directiva es:

session.upload_progress.enabled = 0

En un pool FPM, la sintaxis propia del pool es:

php_admin_flag[session.upload_progress.enabled] = off

No son intercambiables: la segunda es una directiva del archivo de pool FPM. php_admin_flag impide que el código la reemplace con ini_set(), y la configuración debe quedar aplicada antes de procesar la petición. No uses ini_set() ni .user.ini como mitigación de este vector: el problema puede alcanzarse antes de que el código de la aplicación ejecute ese cambio.

Después de editar la configuración, recarga o reinicia el SAPI web y confirma de forma privada que los workers nuevos recibieron el valor. Haz una prueba funcional de subida normal si tu aplicación usa esa ruta; no confundas que la carga funcione con que el tercer CVE ya esté corregido. Cuando llegue una release regular que lo cierre, cambia primero en un entorno controlado, conserva el ajuste funcional y retira la mitigación solo con evidencia de la versión y del proveedor.

Por qué Composer no resuelve el motor

Composer instala y actualiza paquetes declarados en composer.json y composer.lock. Puede ayudarte a revisar la aplicación y sus dependencias, pero no reemplaza el binario PHP, las extensiones, el SAPI, la imagen de contenedor ni los workers. composer audit es complementario para advisories de paquetes; no demuestra que FPM o mod_php estén ejecutando una release corregida.

La actualización debe seguir el canal que administra tu runtime: paquete de la distribución, imagen base, instalador del proveedor o compilación propia. Si el número visible no coincide con 8.5.12, 8.4.27, 8.3.36 o 8.2.35, busca la nota de seguridad del proveedor que documente el backport y registra su identificador. No cambies de rama mayor automáticamente solo para hacer coincidir un número.

Un rollback debe volver a una imagen o paquete conocido y corregido, no reintroducir un worker vulnerable en Internet. Conserva la referencia anterior para recuperar la aplicación, pero mantén el proceso web dentro de una versión que incluya los parches aplicables y vuelve a comprobar todos los workers.

Una comprobación con alcance claro

Una revisión prudente produce cuatro evidencias distintas: versión del paquete o imagen, SAPI que atiende HTTP, configuración efectiva del worker y estado funcional de las cargas. Ninguna por sí sola prueba las otras tres. El aviso crítico menciona PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed porque el punto de entrada importa; una terminal administrativa no representa todos esos procesos.

El objetivo no es afirmar que todas las aplicaciones estén expuestas al aviso de session.upload_progress: PHP describe esa combinación como improbable. El objetivo es no confundir una mitigación estrecha con el parche del motor, ni una salida de CLI con la versión que está detrás del proxy. Parches, configuración y proceso deben quedar alineados antes de retirar la excepción temporal.

Fuentes primarias

• Archivo de noticias de PHP 2026: avisos del 21 y 23 de octubre.
• Advisory GHSA-w8hw-w9fx-j79w: CVE-2026-109618.
• Advisory GHSA-6wmf-4rv5-p3rp: CVE-2026-109619.
• Descargas oficiales de PHP.
• Changelog de PHP 8.
• Configuración de sesiones y session.upload_progress.enabled.
• Configuración de PHP-FPM: php_admin_flag y pools.
• Archivo principal de configuración de PHP.
• Función php_sapi_name().
• Uso básico de Composer.