Actualización del 27 de octubre: la CISA incluye PHP2Shell entre los fallos explotados
El 26 de octubre de 2026, la CISA, la agencia estadounidense de ciberseguridad, añadió los dos fallos (CVE-2026-109618 y CVE-2026-109619) a su catálogo de vulnerabilidades explotadas conocidas, el KEV (Known Exploited Vulnerabilities). Una entrada solo figura ahí cuando se ha establecido una explotación real: hasta ahora, esa constatación se basaba en las trampas de red de watchTowr; ahora procede de una autoridad pública.
La CISA fijó el plazo en el 29 de octubre de 2026, tres días después de la inclusión. Esa fecha solo obliga a las agencias federales estadounidenses, pero da el orden de magnitud de la urgencia que un organismo público atribuye a estos fallos: unos días, no la próxima ventana de mantenimiento mensual.
Qué dice la entrada del catálogo KEV
- Fecha de inclusión: 26 de octubre de 2026, tanto para CVE-2026-109618 («PHP Memory Corruption Vulnerability») como para CVE-2026-109619 («PHP Stale Internal Request-State Vulnerability»).
- Plazo: 29 de octubre de 2026 para ambos.
- Acción exigida: aplicar las mitigaciones del proveedor conforme a la directiva BOD 26-04 (Prioritizing Security Updates Based on Risk), o dejar de usar el producto si no hay ninguna mitigación disponible.
- Triaje forense: la entrada remite a los «Forensics Triage Requirements» de la CISA. Parchear no basta: también hay que buscar una intrusión anterior al parche.
- Ransomware: el uso en una campaña de ransomware figura como «desconocido» por ahora.
Qué cambia para usted
Nada en el procedimiento: las versiones corregidas y los comandos siguen siendo los de este artículo. Lo que cambia es la prioridad. Antes del 26 de octubre aún se podía elegir entre «ahora mismo» y «en la próxima ventana de mantenimiento»; ya no es defendible. Los servidores expuestos a internet van primero. Y la pregunta ya no es solo «¿estoy protegido?», sino «¿me afectó entre el 21 de octubre y el momento en que apliqué el parche?»: la lista de comprobación de más abajo se ha ampliado en ese sentido.
PHP2Shell en resumen
PHP2Shell no es un fallo de WordPress, de Laravel ni de un plugin: lo que está en cuestión es el propio motor de PHP. Por lo tanto, toda aplicación PHP que responda a solicitudes web está afectada, sea cual sea su código. El aviso de seguridad menciona PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
Ambos fallos comparten el mismo mecanismo. Cuando PHP interrumpe bruscamente una solicitud (memoria agotada, error fatal), puede dejar tras de sí un estado interno a medio inicializar o ya liberado. Una solicitud posterior, atendida por el mismo proceso PHP, reutiliza entonces ese estado: eso es lo que abre la puerta a una ejecución remota de código.
Lo que hay que recordar
- CVE-2026-109618 — corrupción de memoria al superar
memory_limit: los datos de la solicitud, inicializados solo en parte, se tratan después como válidos durante la limpieza. - CVE-2026-109619 — estado global obsoleto: un estado propio de una solicitud sobrevive a la liberación de su memoria y puede ser leído por la siguiente solicitud en el mismo proceso.
- Puntuación: 9.2 sobre 10 en CVSS 4.0 para cada una, sin autenticación ni interacción del usuario.
- Versiones corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El proyecto ya no publica versiones para 8.1 ni para las ramas anteriores.
- Explotación: watchTowr informa de intentos de explotación en sus trampas de red desde el 21 de octubre de 2026.
- Alcance: según la NVD, CVE-2026-109619 afecta a todas las versiones desde PHP 5.4.0, y CVE-2026-109618 a todas las versiones desde PHP 7.3.0.
Por qué estos dos fallos son tan peligrosos
La mayoría de los fallos web exigen un formulario concreto, una cuenta o un plugin vulnerable. PHP2Shell no necesita nada de eso: el desencadenante más habitual es el procesamiento de un envío multipart/form-data con el seguimiento del progreso de sesiones (session.upload_progress), un mecanismo que PHP activa por defecto y que se ejecuta antes del primer byte de su aplicación. Un cortafuegos de aplicación ubicado en su código, un plugin de seguridad de WordPress o un middleware de Laravel llegan, por tanto, demasiado tarde.
El segundo factor es el propio modelo de ejecución. PHP-FPM y Apache reutilizan el mismo proceso para cientos de solicitudes sucesivas: eso es precisamente lo que permite que una solicitud maliciosa contamine la siguiente. Según Imperva, las técnicas publicadas van desde la caída de procesos hasta la lectura de archivos arbitrarios a través de la caché OPcache, pasando por la fuga de unos 67 KB de memoria del proceso en una cookie PHPSESSID sobredimensionada. Esa memoria puede contener contraseñas de bases de datos o claves de API.
Qué versión instalar según su rama
Desplace la tabla
| Rama de PHP | Versión corregida | Qué hacer |
|---|---|---|
| 8.5 | 8.5.12 | Actualizar y luego reiniciar PHP |
| 8.4 | 8.4.27 | Actualizar y luego reiniciar PHP |
| 8.3 | 8.3.36 | Actualizar y luego reiniciar PHP |
| 8.2 | 8.2.35 | Actualizar y luego planificar la migración a 8.3 u 8.4 |
| 8.1, 8.0, 7.4 | Ninguna versión oficial | Paquete corregido de su distribución, retroportación del código fuente o, si no, migración |
| 7.3 y anteriores, 5.x | Ningún parche publicado | Migrar a una rama mantenida |
Comprobar si sus servidores están expuestos
Cuidado con una trampa clásica: la versión que muestra php -v en la línea de comandos no es necesariamente la que sirve sus sitios. Un servidor puede tener varias versiones de PHP-FPM instaladas en paralelo, y cada sitio puede apuntar a una versión distinta. Por lo tanto, hay que comprobar la versión que realmente sirve la web, sitio por sitio.
Inventariar las versiones de PHP servidas
Listar las versiones instaladas
En Debian o Ubuntu:
dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'php*' | awk '$1=="ii"' | grep -E 'php[0-9.]+-(fpm|cli|common)|libapache2-mod-php'En RHEL, AlmaLinux o Rocky Linux:
rpm -qa 'php*' 'ea-php*' 'alt-php*' | sortLocalizar los procesos PHP en ejecución
systemctl list-units --type=service --state=running | grep -E 'php|apache2|httpd|lsws'Cada servicio
phpX.Y-fpmactivo es una versión que hay que comprobar y corregir.Leer la versión que sirve un sitio
Coloque un archivo temporal en la raíz del sitio, consúltelo y después elimínelo de inmediato:
echo '<?php echo PHP_VERSION, " ", PHP_SAPI;' > /var/www/monsite/v-check.php curl -s https://monsite.example/v-check.php rm /var/www/monsite/v-check.phpUn resultado
8.3.36 fpm-fcgiindica una versión corregida servida por PHP-FPM.Revisar los contenedores Docker
docker ps --format '{{.Names}}' | while read c; do echo "$c: $(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null)"; doneUn contenedor sin PHP no muestra nada después de su nombre.
Aplicar el parche
Las distribuciones Linux y los proveedores de soporte extendido recibieron los parches antes de la publicación. Por eso, el paquete corregido de su distribución no lleva necesariamente el número 8.3.36: Ubuntu 24.04, por ejemplo, corrige su versión 8.3.6 en el paquete 8.3.6-0ubuntu0.24.04.13. Confíe en el aviso de seguridad de su distribución más que en el número de versión de PHP por sí solo. En cualquier caso, el reinicio es imprescindible: mientras los procesos antiguos sigan en ejecución, es el código antiguo el que responde.
Actualizar PHP según su entorno
Debian y Ubuntu
sudo apt update sudo apt install --only-upgrade $(dpkg-query -W -f='${db:Status-Abbrev} ${Package}\n' 'php*' | awk '$1=="ii"{print $2}') sudo systemctl restart 'php*-fpm' sudo systemctl restart apache2 # si usa mod_phpSi sus versiones proceden de un repositorio de terceros (por ejemplo, el PPA
ondrej/php), compruebe que la versión instalada tras la actualización sea realmente una versión corregida.RHEL, AlmaLinux, Rocky Linux
sudo dnf upgrade 'php*' sudo systemctl restart php-fpm sudo systemctl restart httpdAlmaLinux publicó sus paquetes corregidos el 21 de octubre de 2026. El repositorio comunitario Remi, por su parte, publicó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12 el 22 de octubre de 2026: si depende de él, compruebe después la versión instalada.
Servidor cPanel (EasyApache 4 o CloudLinux)
sudo dnf upgrade 'ea-php*' 'alt-php*' /scripts/restartsrv_apache_php_fpm /scripts/restartsrv_httpdEn un servidor más antiguo, sustituya
dnfporyum. Después, revise cada versión en WHM › MultiPHP Manager: una cuenta configurada en 7.3 o anterior, sin parche en cPanel, debe pasarse a una versión mantenida; 7.4, 8.0 y 8.1 están corregidas por retroporte, pero al final de su vida útil (véase más abajo).Contenedores Docker
docker compose pull docker compose up -d --force-recreate docker compose exec app php -r 'echo PHP_VERSION;'Si su
Dockerfileparte de una imagenphp:8.3-fpm, reconstruya la imagen condocker compose build --pull: sin--pull, Docker reutiliza la antigua imagen base almacenada en caché.Comprobar el resultado
Vuelva a ejecutar la comprobación del paso anterior en cada sitio. El parche solo está aplicado si la versión servida por la web está corregida, no únicamente la versión instalada en el disco.
cPanel y EasyApache 4: un número que no cambia no significa «sin corregir»
El registro de cambios de EasyApache 4 (EA4) del 21 de octubre de 2026, versión 25.91, abarca siete ramas de PHP. En las ramas mantenidas el número sube: ea-php82 pasa de 8.2.34 a 8.2.35, ea-php83 de 8.3.35 a 8.3.36, ea-php84 de 8.4.26 a 8.4.27 y ea-php85 de 8.5.11 a 8.5.12. En ea-php74, ea-php80 y ea-php81, que cPanel había declarado al final de su vida útil, la corrección es retroportada: el número de versión de PHP no cambia, solo la revisión del paquete.
Esa es la trampa: php -v muestra entonces una versión «antigua» aunque el código esté corregido, y una versión antigua cuyo changelog no cita las dos CVE sigue siendo vulnerable. Solo la lectura del changelog del paquete lo decide. Una versión 25.92, publicada el mismo día, reconstruyó además los metapaquetes para que su changelog también mencione el retroporte.
EasyApache 4 25.91: lo que publicó cPanel, paquete por paquete
Desplace la tabla
| Paquete | Qué cambió | Cómo comprobarlo |
|---|---|---|
| ea-php85 | 8.5.11 a 8.5.12 | Versión del paquete |
| ea-php84 | 8.4.26 a 8.4.27 | Versión del paquete |
| ea-php83 | 8.3.35 a 8.3.36 | Versión del paquete |
| ea-php82 | 8.2.34 a 8.2.35 | Versión del paquete |
| ea-php81, ea-php80, ea-php74 | Parche retroportado, número de PHP sin cambios | Changelog RPM: buscar las dos CVE |
| ea-php73 y anteriores | Ninguna entrada en el registro 25.91 | Migrar, o ver CloudLinux más abajo |
Comprobar que un paquete retroportado está realmente corregido
Leer el changelog del paquete EasyApache
rpm -qa 'ea-php*-php-cli' rpm -q --changelog ea-php81-php-cli | grep -E 'CVE-2026-(109618|109619)'El primer comando lista las ramas instaladas; el segundo se repite para cada una. Una línea que cite las CVE confirma la corrección. Ninguna línea: el paquete no está corregido, sea cual sea su número de versión.
Hacer lo mismo con los paquetes alt-php
En un servidor CloudLinux, las versiones elegidas en Select PHP Version son paquetes
alt-php:rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'Repasar las cuentas una por una
En WHM › MultiPHP Manager, cada dominio debe apuntar a una rama cuyo paquete haya superado esta comprobación. Las ramas 7.4, 8.0 y 8.1 corregidas por retroporte siguen al final de su vida útil: son una posición de espera, no un destino.
CloudLinux: la misma corrección, uno o dos días más tarde según el producto
CloudLinux publica sus propios paquetes, y no llegan a la vez que los de cPanel. Según su boletín, los paquetes ea-php (de 5.2 a 8.5) pasaron a estable el 21 de octubre, los alt-php el 22 de octubre en CloudLinux 7, 8 y 9, el PHP nativo del sistema el 22 de octubre a última hora (UTC) y los paquetes numerados como PHP.net el 23 de octubre.
También son retroportes: ea-php84 se queda, por ejemplo, en 8.4.26 con una revisión propia de CloudLinux (8.4.26-2) estando corregido. Dos puntos de atención: el 21 de octubre, unos alt-php anunciados como publicados estaban en realidad en el repositorio TuxCare ELS y no en los de CloudLinux; y el consejo de desactivar el repositorio php-els, dado el 22, se corrigió la noche del 23: déjelo activado. Por último, Imunify360 publicó sus reglas WAF el 21 de octubre (conjunto de reglas 8.83) y la versión 8.88 es estable desde el 23: bloquean vectores conocidos y no sustituyen a la actualización.
El PHP interno de cPanel/WHM y Roundcube: otro PHP que actualizar
MultiPHP y EasyApache gobiernan el PHP de sus sitios. Las interfaces de cPanel y WHM y el webmail Roundcube funcionan, en cambio, con un PHP interno que se entrega con el propio cPanel y que la elección de una versión en MultiPHP Manager no toca. El 21 de octubre de 2026, cPanel publicó una actualización de seguridad para ese PHP interno, precisando que «afecta a PHP en las interfaces de cPanel, incluido el webmail Roundcube».
Entrega PHP 8.4.27 en cPanel & WHM 138.0.18, 136.0.50 y 134.0.66, y correcciones retroportadas para PHP 8.1.34 en la versión 110.0.153. Estas interfaces están abiertas a las conexiones de sus clientes y, por tanto, suelen ser accesibles desde internet: son objetivos prioritarios. Lea su versión con /usr/local/cpanel/cpanel -V (o en el banner de WHM) y compárela con estos números. Si su serie no figura, no la dé por corregida: consulte las notas de versión de cPanel y pase a una serie que lo esté.
Tras el parche, desactive igualmente el seguimiento del progreso de las subidas
El 23 de octubre de 2026, PHP publicó un aviso informativo complementario: recomienda mantener session.upload_progress.enabled=0 hasta la próxima versión de corrección ordinaria, para protegerse de un vector de ejecución de código que considera poco probable. Afecta a las aplicaciones que configuran session.serialize_handler como php_binary o php_serialize y luego lo vuelven a poner en php en tiempo de ejecución con ini_set() antes de session_start(). PHP anuncia un aviso completo para CVE-2026-115560 con la próxima versión. El ajuste solo afecta a la barra de progreso de las subidas de archivos.
Si no puede actualizar de inmediato
El aviso oficial de PHP propone ajustes que reducen la exposición sin hacer que la instalación sea segura. Sirven para ganar unas horas, no para sustituir el parche. Deben establecerse en php.ini, en el pool de PHP-FPM o en la configuración del servidor web, nunca mediante ini_set() ni con un archivo .user.ini: estos últimos se leen demasiado tarde, después del análisis de la solicitud.
Contra CVE-2026-109619, desactive el seguimiento del progreso de los envíos. En PHP 8.5, desactive también las trazas de errores fatales:
; en el pool FPM, por ejemplo /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
; solo PHP 8.5:
php_admin_flag[fatal_error_backtraces] = offContra CVE-2026-109618, el aviso recomienda memory_limit = -1 impuesto mediante php_admin_value, para que ninguna aplicación pueda redefinirlo, y un tamaño de solicitud acotado (post_max_size = 8M, o 32M si necesita envíos de archivos). A cambio, la memoria debe limitarse en otro lugar, mediante un límite de contenedor o de cgroup. No utilice RLIMIT_AS ni RLIMIT_DATA: son precisamente los que provocan el fallo de asignación vulnerable.
Después, reinicie todos los procesos PHP para que los ajustes se apliquen.
Añada una barrera delante de PHP
Limite el tamaño de las solicitudes en el servidor web, antes de que lleguen a PHP: client_max_body_size 8m; en nginx, LimitRequestBody 8388608 en Apache. Si su sitio pasa por Cloudflare en modo proxy, se han desplegado reglas WAF dirigidas a los vectores conocidos de PHP2Shell para todas las cuentas, incluido el plan gratuito. Son redes de seguridad: solo la actualización de PHP cierra el fallo.
Buscar rastros de explotación
Los intentos publicados dejan rastros característicos: procesos PHP que se caen, desbordamientos de memoria en ráfaga y envíos multipart anormalmente voluminosos. Si su servidor estuvo expuesto antes de la actualización, dedique diez minutos a comprobarlo.
Controles que realizar después del parche
Buscar los procesos PHP-FPM terminados
sudo grep -E 'exited on signal (11|6)' /var/log/php*-fpm.log | tail -20Una serie de procesos terminados por la señal 11 (SIGSEGV) desde el 21 de octubre es una señal de alerta.
Buscar los desbordamientos de memoria
sudo grep -rh 'Allowed memory size' /var/log/php* /var/log/nginx /var/log/apache2 2>/dev/null | tail -20Localizar los archivos PHP creados recientemente
sudo find /var/www /home -name '*.php' -newermt '2026-10-20' -not -path '*/vendor/*' -not -path '*/cache/*' -lsUn archivo desconocido con un nombre genérico, en una carpeta de subidas o en
/tmp, debe examinarse antes de eliminarlo.En caso de duda, tratar el servidor como comprometido
Aísle la máquina, conserve una copia de los registros y, a continuación, renueve las contraseñas de la base de datos, las claves de API y los secretos presentes en los archivos
.env: una fuga de memoria puede haberlos expuesto sin dejar ningún otro rastro.
Otras señales que buscar, según las fuentes primarias
- Solicitudes
multipartanormalmente voluminosas o muy anidadas en los registros del servidor web (watchTowr). - Procesos PHP que fallan o alcanzan su límite de memoria (watchTowr).
- Archivos escritos en las raíces web y conexiones salientes de procesos PHP que no sepa explicar (watchTowr).
- Nuevos web shells, tareas cron inesperadas y cuentas creadas recientemente vinculadas a procesos PHP (watchTowr).
- Conservar antes de limpiar: registros de PHP y del servidor web, instantáneas de configuración y archivos sospechosos, antes de modificar nada (watchTowr). La CISA asocia además a su entrada KEV requisitos de triaje forense.
- No se publica ningún indicador concreto: a 27 de octubre, ni watchTowr, ni PHP, ni el aviso de GitHub de CVE-2026-109618 dan una dirección IP, un hash, un nombre de archivo o una firma de solicitud. Desconfíe de las listas de indicadores sin fuente: la ausencia de una dirección en sus registros no prueba nada.
En un alojamiento compartido
En un alojamiento compartido, no es usted quien actualiza PHP: es el proveedor de alojamiento quien mantiene las versiones disponibles. Su parte del trabajo consiste en comprobar que su sitio utiliza una rama que todavía recibe parches. En cPanel, la herramienta de selección de versión (MultiPHP Manager, o Select PHP Version en un servidor CloudLinux) indica la versión activa de cada dominio. Si su sitio todavía funciona con 7.4, 8.0 u 8.1, esas ramas ya no reciben versiones oficiales de PHP: cambie a 8.3 u 8.4 después de probar su sitio, siguiendo nuestra lista de comprobación para migrar PHP.
La documentación oficial
Los detalles técnicos y los ajustes de mitigación se publican en el aviso de seguridad de PHP y en los avisos de GitHub GHSA-w8hw-w9fx-j79w (CVE-2026-109618) y GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). Para los paquetes de distribución, consulte el anuncio de Ubuntu y el de AlmaLinux. Para el seguimiento: el catálogo KEV de la CISA, el registro de cambios de EasyApache 4, las notas de versión de cPanel & WHM, el boletín de CloudLinux y las preguntas frecuentes de watchTowr.
