En resumen: CVE-2026-109618 es una de las dos vulnerabilidades que hay detrás de PHP2Shell. Un estado de falta de memoria (Out of Memory) puede interrumpir PHP mientras los datos de la petición están inicializados solo en parte; al limpiar, datos no válidos pueden pasar por válidos. Eso permite ejecutar código sin autenticación. El fallo está corregido en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
¿Qué es CVE-2026-109618?
CVE-2026-109618 (identificador de GitHub GHSA-w8hw-w9fx-j79w) es una vulnerabilidad de error de memoria en el núcleo de PHP. Tiene una puntuación CVSS v4.0 de 9.2. Junto con CVE-2026-109619 forma lo que los medios denominan PHP2Shell.
El efecto es una llamada unauthenticated Remote Code Execution: un atacante puede ejecutar código en el servidor web de forma remota y sin cuenta de usuario. Con ello, la vulnerabilidad pertenece a la clase más peligrosa de debilidades que puede tener un servidor web.
Cómo surge la vulnerabilidad, en líneas generales
Cuando PHP procesa una petición web, crea internamente estructuras de datos para esa petición, por ejemplo para los datos de formulario enviados. Si PHP alcanza entonces su límite de memoria, se interrumpe con un estado de falta de memoria. Según php.net, esto puede ocurrir mientras los datos de la petición están inicializados solo en parte.
Al final de cada petición, PHP limpia y libera la memoria. Justo ahí está el fallo: la limpieza puede tratar como válidos datos no válidos, creados solo a medias. De este comportamiento erróneo puede derivarse, bajo ciertas condiciones, la ejecución de código.
¿Por qué es tan grave un fallo así? Un error de memoria en el lenguaje de programación afecta a todas las aplicaciones que se ejecutan sobre él, con independencia de lo cuidadosamente que estén programadas. Una instalación de WordPress bien mantenida y con plugins actualizados está tan afectada como un antiguo desarrollo propio. Por eso aquí no ayuda una actualización de la aplicación, sino solo una actualización de PHP.
Deliberadamente no publicamos más detalles técnicos sobre la explotación. Para la defensa no son necesarios: lo decisivo es si su servidor usa una versión corregida y si los procesos nuevos se están ejecutando realmente.
Versiones y modos de ejecución afectados
| Rama de PHP | Último estado antes de la corrección | Corregido desde |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
| 8.1 y anteriores | sin actualización oficial | solo backports mínimos de código fuente para 7.4, 8.0, 8.1 |
Están afectados los modos de ejecución PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera que el riesgo es mayor en mod_php. Las distribuciones y los proveedores de hosting incorporan en ocasiones backports, de modo que se muestra un número de versión más antiguo aunque el fallo esté corregido. Lo determinante son el estado del paquete y la confirmación del proveedor.
Sobre el orden de magnitud: Palo Alto Networks (Unit 42) contabilizó más de 22,6 millones de instancias expuestas y potencialmente vulnerables. El BSI (Oficina Federal alemana para la Seguridad de la Información) ha declarado el nivel de alerta 3 (naranja) y esperaba una explotación rápida y a gran escala.
Corregir CVE-2026-109618: actualización y reinicio
El único remedio completo es la actualización. Compruebe primero la versión y el estado del paquete. Los nombres de los paquetes varían según la distribución; los ejemplos parten de PHP 8.3:
php -v
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"
Si el changelog del paquete menciona el número CVE, el backport está instalado. Si no aparece, no significa automáticamente que el paquete sea vulnerable; entonces ayuda el contraste con la tabla de versiones o la consulta al proveedor.
Tras la actualización hay que reiniciar todos los procesos de PHP, por ejemplo con systemctl restart php8.3-fpm o, en mod_php, con un reinicio de Apache. Cómo asegurarse de que ya no queda ningún worker antiguo se explica en Reiniciar PHP-FPM y todos los workers.
Medidas provisionales si todavía no es posible actualizar
php.net ha publicado medidas provisionales para PHP2Shell. Valen para ambas vulnerabilidades en conjunto y expresamente no son una protección completa. Que varias de ellas se refieran a límites de memoria encaja con el desencadenante de falta de memoria de CVE-2026-109618; sin embargo, no existe una asignación oficial de cada medida a cada CVE.
; Ejemplo de pool de FPM, p. ej. /etc/php/8.3/fpm/pool.d/www.conf (la ruta varía según la distribución)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M ; 32M si se necesitan cargas de archivos
php_admin_value[upload_max_filesize] = 6M ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off
Los valores deben fijarse de modo que las aplicaciones no puedan sobrescribirlos; por eso php_admin_value. Con memory_limit=-1, el servicio necesita un límite de memoria desde fuera, mediante contenedor o cgroup, no mediante RLIMIT_AS ni RLIMIT_DATA. En PHP 8.5 se añade fatal_error_backtraces=0. Todos los detalles figuran en Medidas inmediatas si todavía no puede parchear.
Si no son posibles de inmediato ni la actualización ni las medidas provisionales, el BSI recomienda desconectar temporalmente de la red los servidores web afectados.
¿Cómo ayuda PHP SOS en concreto?
Con nuestro servicio de parcheo de PHP cerramos CVE-2026-109618 de forma estructurada:
- Registrar la situación actual: rama de PHP, modo de ejecución, origen del paquete y estado de backport de cada servidor.
- Instalar la actualización desde el origen de paquetes adecuado o, donde no sea posible, fijar correctamente las medidas provisionales en la configuración del pool o del servidor.
- Comprobar el reinicio: verificamos que ya no se ejecuta ningún proceso antiguo de PHP.
- Justificante: recibirá una documentación con versiones y estados de paquete antes y después de la intervención, por ejemplo para la dirección, la aseguradora o la protección de datos.
Preguntas frecuentes
¿Cómo de crítica es CVE-2026-109618?
La vulnerabilidad tiene una puntuación CVSS v4.0 de 9.2 y, por tanto, es crítica. Permite ejecutar código malicioso de forma remota sin autenticación. El BSI ha declarado para PHP2Shell el nivel de alerta 3 (naranja).
¿Basta con subir memory_limit?
No. php.net menciona memory_limit=-1, fijado de forma definitiva en la configuración del servidor, como una de varias medidas provisionales. Expresamente no es una protección completa y requiere un límite de memoria mediante contenedor o cgroup. La solución sigue siendo la actualización.
¿Qué identificador GHSA corresponde a CVE-2026-109618?
En el GitHub Security Advisory, la vulnerabilidad figura como GHSA-w8hw-w9fx-j79w. La segunda vulnerabilidad de PHP2Shell, CVE-2026-109619, tiene el identificador GHSA-6wmf-4rv5-p3rp.