Vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619

Se han hecho públicas las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, que permiten la ejecución remota de código (RCE) sin autenticación durante la gestión de estados de las solicitudes y las terminaciones anómalas del motor principal de PHP. El problema no afecta a aplicaciones web como WordPress o gnuboard, sino a defectos de corrupción de memoria y uso tras liberación (Use-After-Free) del propio motor de ejecución de PHP. Para solucionarlo, actualice inmediatamente a versiones con los parches de seguridad aplicados, como PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, y reinicie los procesos de trabajo.

Una vulnerabilidad del motor de PHP que no se puede bloquear actualizando solo la aplicación web

El 21 de octubre de 2026 (UTC), el equipo de desarrollo de PHP anunció dos vulnerabilidades de seguridad con una gravedad de 9,2 según CVSS v4.0. Un atacante puede ejecutar código arbitrario en el servidor simplemente enviando una solicitud HTTP manipulada, sin necesidad de iniciar sesión.

Estos defectos se producen en la capa principal de PHP, que analiza las solicitudes web y libera la memoria. Por tanto, aunque se mantengan actualizados el CMS y los plugins del sitio, este seguirá expuesto si el propio entorno de ejecución de PHP está desactualizado. En particular, se ha confirmado que, en entornos Apache con la configuración predeterminada de mod_php, basta una única solicitud para ejecutar código antes incluso de que se ejecute el código de la aplicación web.

Si el ataque tiene éxito, el intruso obtiene los permisos de la cuenta del sistema con la que se ejecuta el proceso de PHP. Aunque esto no implica obtener inmediatamente permisos de root, puede crear una webshell en el directorio raíz web o consultar las credenciales de acceso a la base de datos registradas en los archivos de configuración para exfiltrar o modificar datos internos. Si varios sitios web de un mismo servidor comparten la misma cuenta de ejecución de PHP-FPM, existe además el riesgo de que la intrusión de un sitio se extienda a otros sitios del servidor.

Principio de la corrupción de memoria y el uso tras liberación durante una terminación anómala

Ambas vulnerabilidades se producen porque la memoria no se libera correctamente cuando surge una situación excepcional durante el procesamiento de una solicitud. Las condiciones de activación y el funcionamiento interno son diferentes en cada caso.

CVE-2026-109618 (corrupción de memoria durante el procesamiento de un límite de memoria excedido): cuando PHP supera el límite de memoria permitido (Out-Of-Memory) al procesar una solicitud, llama a longjmp() para detener inmediatamente la ejecución. Si el proceso se detiene cuando las estructuras de datos internas de la solicitud todavía no se han inicializado por completo, el estado incompleto puede quedar sin revertirse. Posteriormente, la rutina de limpieza (cleanup) de la solicitud confía en esa memoria no inicializada como si contuviera datos válidos y accede a ella, lo que puede provocar corrupción de memoria y ejecución remota de código.

CVE-2026-109619 (Use-After-Free al referenciar memoria liberada de una solicitud anterior): algunos estados globales internos de PHP o estados de gestión de errores apuntan temporalmente a un área de memoria propiedad de una única solicitud. Cuando la solicitud termina de forma anómala por un error fatal (fatal error) o por falta de memoria, la memoria real se libera, pero en algunos casos la referencia del puntero interno que apuntaba a ella no se inicializa y permanece. En entornos que reutilizan los procesos de trabajo, como PHP-FPM o mod_php, cuando el mismo proceso recibe y procesa la siguiente solicitud HTTP, vuelve a leer el área de memoria ya liberada (Use-After-Free), creando una vía para ejecutar código.

El aviso de seguridad oficial menciona como vías confirmadas de CVE-2026-109619 la función de progreso de subida de sesiones (session.upload_progress), las advertencias de configuración que se muestran antes de inicializar la solicitud y las trazas de errores fatales de PHP 8.5 (fatal_error_backtraces). No obstante, también indica que pueden quedar otras vías alternativas aunque se bloqueen estas.

Estado de los parches por versión de PHP y alcance según el entorno de ejecución

Están afectadas las versiones de PHP 8.2 a 8.5 inferiores a las versiones corregidas. Las versiones 8.1 e inferiores, cuyo soporte ha finalizado, no forman parte de las actualizaciones oficiales del proyecto PHP. En cuanto al modo de ejecución, están afectadas todas las instalaciones que procesan solicitudes web, incluidas PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed; el aviso oficial considera que mod_php presenta el mayor riesgo. Red Hat clasifica PHP-FPM como potencialmente afectado de forma condicional a través de vías de la fase de aplicación.

Entorno verificado: a fecha de 22 de octubre de 2026, en un servidor Linux que utiliza el repositorio Remi, se actualizó PHP 8.4.26 a 8.4.27 y se verificaron el reinicio de los trabajadores de PHP-FPM y la aplicación a las solicitudes web.

Procedimiento para actualizar los paquetes y aplicar la configuración de mitigación de PHP-FPM

El equipo de desarrollo de PHP indica que un cambio de configuración por sí solo no puede bloquear todas las vías de ataque y que actualizar a una versión corregida es la única solución completa. Después de actualizar, también se pueden aplicar medidas de mitigación que desactiven funciones innecesarias para reducir la superficie de ataque.

1. Instalar la actualización de los paquetes de PHP
   Actualice los paquetes mediante el gestor de paquetes del sistema operativo a la versión corregida de la serie de PHP utilizada, por ejemplo, 8.4.27 para la serie 8.4. Tras la instalación, compruebe primero la versión de CLI desde el terminal.

   php -v

   Al ejecutar el comando, se mostrarán en pantalla el número de versión actualizado y la fecha de compilación, por ejemplo PHP 8.4.27 (cli). Sin embargo, la versión de CLI puede diferir de la versión del proceso de PHP con el que se integra realmente el servidor web, por lo que debe completar necesariamente el paso siguiente.

2. Ajustar la configuración de PHP-FPM para reducir la superficie de ataque (opcional y mitigación temporal)
   Si resulta difícil aplicar de inmediato la actualización o se desea añadir una capa de defensa, haga una copia de seguridad de php.ini o del archivo de configuración del pool de PHP-FPM, por ejemplo /etc/php-fpm.d/www.conf, y ajuste los elementos siguientes.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   Desactivar session.upload_progress.enabled puede bloquear la vía de ataque basada en sesiones que se ha confirmado. Reducir post_max_size —por ejemplo, a 8M en entornos que no necesiten subir archivos o a 32M en los que sí los necesiten— dificulta los intentos de agotar la memoria mediante solicitudes de gran tamaño. Teniendo en cuenta el tamaño de las cabeceras adicionales de multipart, establezca upload_max_filesize ligeramente por debajo de post_max_size. En entornos PHP 8.5, aplique también fatal_error_backtraces = 0.

3. Comprobar la sintaxis de PHP-FPM y reiniciar los procesos
   Después de guardar la configuración, compruebe que no haya errores de sintaxis y reinicie el servicio PHP-FPM.

   php-fpm -t
   systemctl restart php-fpm

   Si no hay problemas de configuración al ejecutar php-fpm -t, se mostrará en pantalla el mensaje NOTICE: configuration file ... test is successful. Es necesario reiniciar los procesos de trabajo para terminar los procesos antiguos que permanecían en memoria y aplicar la nueva versión corregida y la configuración.

4. Comprobar la versión realmente aplicada mediante una solicitud web
   Acceda a la pestaña de información «Estado del sitio (Site Health)» de WordPress o a una página de diagnóstico de la integración con el servidor web para confirmar que el trabajador de PHP-FPM que procesa las solicitudes web responde con una versión corregida, como 8.4.27. Si existe algún archivo PHP de diagnóstico creado temporalmente para la comprobación, elimínelo inmediatamente después para evitar que la información del sistema quede expuesta externamente.

Qué hacer si se retrasa la actualización o aparecen efectos secundarios tras cambiar la configuración

El paquete no se puede descargar porque la actualización de los mirrors de repositorios de terceros, como Remi, se retrasa

Inmediatamente después de un parche de seguridad urgente, la concentración de tráfico o los retrasos de sincronización pueden impedir que los paquetes de actualización aparezcan en el repositorio de terceros, por ejemplo rpms.remirepo.net, o pueden reducir la velocidad de descarga. El aviso oficial indica que las actualizaciones de este repositorio, gestionado por voluntarios, no se publican el mismo día del anuncio y recomienda cambiar a paquetes del distribuidor o a una compilación desde el código fuente.

En este caso, puede especificar directamente en la configuración del repositorio la dirección de un servidor mirror que se haya sincronizado y funcione a una velocidad normal, y después realizar la actualización. Aunque cambie manualmente el mirror, debe mantener activada la comprobación de firmas GPG (gpgcheck=1) para impedir la manipulación de los paquetes. Si no es posible utilizar un mirror, use los paquetes oficiales de backport de la distribución del sistema operativo o compile y aplique directamente el código fuente.

Se teme falta de memoria (OOM) o rechazo de subidas al aplicar la configuración de mitigación

El aviso oficial propone memory_limit = -1 (sin límite) como mitigación para CVE-2026-109618 cuando no sea posible actualizar de inmediato, y recomienda establecer al mismo tiempo un límite de memoria para el contenedor o cgroup. Sin embargo, si se elimina el límite de memoria en un servidor con poca memoria física, una sola solicitud puede consumir toda la memoria del servidor y provocar que el OOM Killer del sistema operativo fuerce la terminación de un demonio esencial. Esta configuración es una medida temporal hasta la actualización; después de actualizar a una versión corregida, es más seguro restaurar el límite de memoria original.

Además, antes de reducir post_max_size respecto al valor anterior, por ejemplo, 64MB, debe comprobar el método de transferencia de archivos del sitio. Los sitios que suben directamente archivos de copia de seguridad o plugins de gran tamaño desde una página web de administración pueden sufrir el bloqueo de las solicitudes. En cambio, si los archivos grandes se transfieren mediante SFTP o rsync, o si la propia aplicación ya tiene un límite de 30MB o menos, reducir a 32MB el límite de subida de PHP no afectará al servicio.

Por otro lado, si después de actualizar la versión de PHP los trabajadores de PHP-FPM terminan de forma intermitente, puede ser conveniente revisar la configuración de compilación JIT (Just-In-Time) de OPcache. La función JIT, por ejemplo opcache.jit=1255, no está directamente relacionada con esta vulnerabilidad de seguridad, pero si existen antecedentes de problemas de estabilidad al cambiar de versión, puede desactivarse con opcache.jit=off en el archivo de configuración para evitar conflictos.

Preguntas frecuentes

¿Se soluciona actualizando WordPress o los plugins a la última versión?

No. Esta vulnerabilidad se produce en el motor principal de PHP, antes de que se ejecuten WordPress o los plugins de seguridad. Aunque es posible bloquear temporalmente los patrones de ataque conocidos mediante un firewall de aplicaciones web, como Cloudflare o AWS WAF, para solucionar el problema de raíz debe actualizar la propia versión de PHP del servidor a través del proveedor de alojamiento o del administrador del servidor.

¿Es seguro no actualizar si se desactiva session.upload_progress.enabled?

No es seguro. El aviso oficial indica que esta configuración solo bloquea la vía de sesión confirmada y no las variantes restantes. Además, la configuración debe establecerse antes de interpretar la solicitud, en lugares como php.ini, el pool de FPM o la configuración del servidor, y no mediante ini_set() o el .user.ini de FPM; también hay que reiniciar todos los trabajadores. La única solución completa es instalar el parche.

Si se ha aplicado el parche, ¿se puede volver a producción sin comprobaciones adicionales?

La actualización bloquea futuros ataques, pero no indica si el sistema ya había sido comprometido. Por ello, después de actualizar conviene comprobar por separado si hubo una intrusión previa. Revise si existen archivos PHP creados o modificados recientemente de forma anómala, como webshells, en los directorios web, e investigue los registros de acceso del servidor web y los registros de errores de PHP para detectar solicitudes POST anormalmente grandes o registros repetidos de errores de memoria.

¿Cómo se debe actuar en entornos de contenedores o imágenes en la nube?

Aunque se actualicen los paquetes del servidor anfitrión, el entorno de ejecución de PHP incluido dentro del contenedor no cambia automáticamente. Por tanto, debe volver a compilar y redistribuir la imagen del contenedor utilizando una imagen base que incluya las versiones corregidas, 8.5.12, 8.4.27, 8.3.36 o 8.2.35.

Fuentes

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (en coreano)