En resumen: CVE-2026-109619 es la segunda vulnerabilidad que hay detrás de PHP2Shell. El estado interno que pertenece a una petición puede persistir tras liberar la memoria; una petición posterior en el mismo worker puede aprovecharlo antes de que se restablezca. La consecuencia es la ejecución de código sin autenticación. Solución: actualizar a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y reiniciar todos los workers.
¿Qué es CVE-2026-109619?
CVE-2026-109619 (identificador de GitHub GHSA-6wmf-4rv5-p3rp) tiene una puntuación CVSS v4.0 de 9.2. Junto con CVE-2026-109618 forma PHP2Shell. Ambas vulnerabilidades están en el propio PHP y no en una aplicación.
El efecto es el mismo que en la vulnerabilidad hermana: un atacante puede ejecutar código en el servidor de forma remota, sin contraseña y sin cuenta de usuario. Pero la causa es otra.
Por qué es peligroso el estado obsoleto en el worker
Un servidor web con PHP no inicia un proceso nuevo para cada petición. En PHP-FPM, Apache con mod_php, LiteSpeed o FrankenPHP, un worker atiende muchas peticiones una tras otra. Entre dos peticiones, PHP restablece su estado interno para que nada de la petición A pase a la petición B.
En CVE-2026-109619, este restablecimiento no funciona del todo. Según php.net, el estado interno que pertenece a la petición puede persistir tras liberar la memoria. Una petición posterior en el mismo worker puede aprovechar ese estado obsoleto antes de que se restablezca. Dicho de forma simplificada: se sigue usando algo que en realidad ya no es válido.
Desde el punto de vista operativo, esto es llamativo. La reutilización de los workers es intencionada, porque hace rápido al servidor web: un worker no tiene que reiniciarse para cada petición, cargar extensiones y reservar memoria. La vulnerabilidad afecta, por tanto, a una característica que tiene prácticamente toda instalación de PHP en producción. php.net no menciona ninguna configuración que evite por completo el problema; por eso el camino pasa por la actualización.
No publicamos detalles sobre la explotación. Para los operadores cuenta esto: hay que vigilar todo modo de ejecución en el que los workers atiendan varias peticiones, y esos son justamente los modos habituales.
Las dos vulnerabilidades de PHP2Shell, comparadas
| Característica | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Identificador de GitHub | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Puntuación | CVSS v4.0 9.2 | CVSS v4.0 9.2 |
| Desencadenante | falta de memoria durante la inicialización de los datos de la petición | el estado interno persiste tras la liberación |
| Efecto | ejecución de código sin autenticación | ejecución de código sin autenticación |
| Corregida en | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Están afectados PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP ve el mayor riesgo en mod_php; por qué, lo explicamos en Por qué mod_php soporta el mayor riesgo.
Cerrar CVE-2026-109619: actualizar y reiniciar todos los workers
Precisamente en esta vulnerabilidad el reinicio es decisivo. Mientras haya workers antiguos en ejecución en memoria, el servidor sigue trabajando con el código defectuoso, aunque los archivos nuevos lleven tiempo en el disco.
Compruebe la versión y el estado del paquete. Los nombres de los paquetes varían según la distribución y la interfaz del proveedor de hosting:
php -v
php-fpm8.3 -v # el binario de FPM puede tener otra versión que la CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # familia RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Después, reinicie todos los servicios afectados:
sudo systemctl restart php8.3-fpm # según la versión de PHP instalada
sudo systemctl restart apache2 # con mod_php; en RHEL el servicio se llama httpd
Si su distribución o su proveedor de hosting incorpora un backport, el número de versión mostrado puede seguir igual. Entonces cuentan el changelog del paquete y la confirmación por escrito del proveedor. Encontrará una comprobación paso a paso en Reiniciar PHP-FPM y todos los workers.
Anote la fecha y la hora del reinicio. Para valorar después si un ataque tuvo lugar antes o después del parche, ese momento es el punto de referencia más importante.
Lo que queda por hacer después del parche
Un parche no demuestra que antes no hubiera pasado nada. Según informes de los medios, se observó un primer intento de ataque el 17 de octubre, cuatro días antes de los parches. Conserve los registros del servidor desde el 20 de octubre, como recomienda la prensa especializada, y revise el servidor en busca de anomalías. Encontrará indicaciones en la página ¿Ya estoy comprometido?.
Piense también en el alcance: si la ejecución de código tiene éxito, el atacante tiene los permisos del proceso de PHP. Puede leer lo que la aplicación puede leer, por ejemplo archivos de configuración con accesos a bases de datos o claves de API. Si se confirma un incidente, esas credenciales deben renovarse después de la limpieza.
¿Cómo ayuda PHP SOS en concreto?
Con el servicio de parcheo de PHP aplicamos la corrección de forma trazable:
- Registrar: ¿qué versiones de PHP y modos de ejecución hay en cada servidor, y qué origen de paquetes los proporciona?
- Parchear: actualización desde el origen correcto o medidas provisionales según php.net donde la actualización aún esté bloqueada.
- Controlar el reinicio: comprobamos proceso por proceso que solo se ejecuta ya la versión corregida.
- Documentar: versiones, estados de paquete y momentos de reinicio, para que pueda demostrar el estado.
Preguntas frecuentes
¿En qué se diferencia CVE-2026-109619 de CVE-2026-109618?
CVE-2026-109618 surge cuando un estado de falta de memoria interrumpe la petición en plena inicialización. CVE-2026-109619 afecta a un estado que queda en el worker tras terminar una petición. Ambas llevan a la ejecución de código sin autenticación y están corregidas en las mismas versiones de PHP.
¿Sirve de algo reiniciar con más frecuencia los workers de PHP-FPM?
Como sustituto de la actualización no es adecuado. php.net no menciona los reinicios más frecuentes de workers como medida provisional. Sin embargo, sí debe reiniciar los workers después de la actualización, para que se ejecute realmente la versión corregida.
¿Me protege una actualización del CMS frente a CVE-2026-109619?
No. La vulnerabilidad está en PHP y no en WordPress, Shopware, TYPO3 ni otro sistema. Solo la cierran una actualización de PHP o un backport confirmado del proveedor.
¿Hay rastros conocidos de un ataque mediante CVE-2026-109619?
Hasta ahora no se han publicado indicadores de compromiso confirmados. La detección se basa en el análisis del comportamiento, por ejemplo archivos PHP nuevos, conexiones salientes inusuales o tareas cron desconocidas.