Resumen ejecutivo
El equipo de seguridad de PHP ha publicado correcciones para dos vulnerabilidades críticas, conocidas conjuntamente como PHP2Shell (CVE-2026-109618 y CVE-2026-109619), que pueden permitir la ejecución remota de código sin autenticación. Ambas tienen una puntuación CVSS 4.0 de 9.2 (crítica). Desde el 21 de octubre, varias empresas de seguridad (watchTowr, Cloudflare) informan de explotación activa; otras fuentes indican que por ahora predominan los escaneos y que los exploits públicos fiables son escasos; además, no se han publicado indicadores de compromiso (IoC) oficiales. Como la única solución completa es actualizar a las versiones corregidas, este documento recoge, a partir de la información oficial del equipo de seguridad de PHP y de los avisos de las principales distribuciones y fabricantes, los pasos para comprobar si un sistema está afectado, aplicar la corrección y buscar posibles señales de explotación.
Recursos afectados
- PHP 8.2.x (anterior a 8.2.35)
- PHP 8.3.x (anterior a 8.3.36)
- PHP 8.4.x (anterior a 8.4.27)
- PHP 8.5.x (anterior a 8.5.12)
- PHP 8.1 y anteriores (sin soporte oficial; existen parches para las ramas 7.4, 8.0 y 8.1)
Análisis técnico
- CVE-2026-109618: PHP presenta una vulnerabilidad que permite la ejecución remota de código (RCE) debido a un manejo inadecuado de errores de falta de memoria (OOM). Esta falla puede dejar la memoria de la solicitud en un estado no inicializado, lo que permite que el procedimiento de limpieza lea o actúe sobre dicha memoria. Varias estrategias de OOM pueden desencadenar de manera consistente esta condición.
- CVE-2026-109619: PHP presenta una vulnerabilidad donde el estado global no se reinicia correctamente, lo que puede llevar a que se referencie memoria de una solicitud ya liberada. Esto puede permitir que solicitudes posteriores lean o usen este estado obsoleto antes de su inicialización completa, incrementando el riesgo de ejecución remota de código (RCE). La explotación depende de diversas estrategias que pueden desencadenar esta condición.
Mitigación / Solución
Actualizar de inmediato a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o instalar los paquetes de seguridad corregidos proporcionados por la distribución, y reiniciar los servicios que utilizan PHP (apartados 3 y 4). Para PHP 8.1 y versiones anteriores, que ya no reciben nuevas versiones oficiales, consultar las correcciones disponibles del proveedor LTS o de la distribución, o migrar a una versión con soporte. En entornos con contenedores, actualizar las imágenes a versiones corregidas y volver a desplegarlas.
Si no es posible actualizar inmediatamente, aplicar las medidas temporales del apartado 5, entre ellas configurar memory_limit=-1, reducir post_max_size y establecer session.upload_progress.enabled=0 (mitigación parcial de CVE-2026-109619). Según el equipo de seguridad de PHP, estas medidas pueden reducir la exposición, pero no eliminan las vulnerabilidades. La única solución completa es instalar las actualizaciones de seguridad correspondientes.
1. ¿Qué sistemas están en riesgo?
- Cualquier instalación de PHP que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor en mod_php (php.net).
- El ataque se realiza con una petición HTTP sin autenticación y se produce antes de que se ejecute el código de la aplicación. Por tanto, ni la autenticación de la aplicación ni tener el CMS actualizado protegen.
- Según Red Hat, la explotación es más difícil con PHP-FPM; aun así, php.net incluye PHP-FPM entre las instalaciones en riesgo. Actualizar en cualquier caso.
- No están en riesgo los sistemas sin PHP instalado ni los que no exponen PHP a peticiones HTTP no confiables (Red Hat).
2. Inventario: dónde buscar PHP
- Paquetes del sistema: php, php-fpm, php8.x, libapache2-mod-php y similares.
- Paneles de alojamiento (cPanel, Plesk...): suelen tener varias versiones de PHP instaladas a la vez; hay que revisarlas todas.
- Contenedores: PHP va dentro de la imagen. Hay que actualizar la imagen base y reconstruir los contenedores.
- Windows: instalaciones descomprimidas y paquetes como XAMPP, WampServer o Laragon, que a menudo no aparecen como aplicaciones instaladas.
- Productos de terceros con PHP integrado y servicios de alojamiento gestionado o SaaS: preguntar al proveedor si ha aplicado la corrección.
3. Comprobar la versión instalada
- Versiones oficiales corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35, o posteriores.
- Versión de la línea de comandos: php -v. El servicio web (FPM o mod_php) puede usar otra versión; comprobar el binario de cada servicio, por ejemplo sudo php-fpm8.3 -v (el nombre varía según la distribución). mod_php no tiene binario que ejecutar: comprobar la versión del paquete (libapache2-mod-php8.x en Debian/Ubuntu, php en RHEL).
- Importante: las distribuciones Linux suelen aplicar la corrección sin cambiar el número de versión. Por ejemplo, Ubuntu 24.04 sigue mostrando «8.3.6» aunque esté corregido. En paquetes de distribución hay que comprobar la versión del paquete, no el resultado de php -v.
- Debian y Ubuntu: dpkg -l '*php*' | grep ^ii. Versiones mínimas de paquete que corrigen CVE-2026-109618:
· Debian 13 (trixie), php8.4: 8.4.27-1~deb13u1 (DSA-6574-1)
· Debian 12 (bookworm), php8.2: 8.2.35-1~deb12u1 (DLA-4848-1)
· Ubuntu 26.10, php8.5: 8.5.9-0ubuntu2.1
· Ubuntu 26.04 LTS, php8.5: 8.5.4-0ubuntu1.5
· Ubuntu 24.04 LTS, php8.3: 8.3.6-0ubuntu0.24.04.13
· Ubuntu 22.04 LTS, php8.1: 8.1.2-1ubuntu2.28
· Ubuntu 20.04 LTS y anteriores: correcciones solo mediante Ubuntu Pro (ESM); por ejemplo, 20.04, php7.4: 7.4.3-4ubuntu2.29+esm5
- CVE-2026-109619: a fecha de este documento, Debian solo la da por corregida en Debian 13 (8.4.27-1~deb13u1); Debian 12 y testing/unstable siguen vulnerables. El tracker de Ubuntu la marca como «pendiente de evaluación», aunque el blog de Ubuntu anuncia correcciones para PHP2Shell. Consultar el estado actualizado antes de dar un sistema por corregido y, mientras tanto, aplicar las medidas del paso 5.
- RHEL y derivadas: rpm -qa '*php*' y dnf updateinfo list --all --cve CVE-2026-109618,CVE-2026-109619 (en RHEL 7, yum en lugar de dnf). Un resultado vacío no significa que el sistema esté corregido: puede que la corrección aún no se haya publicado. Están afectadas RHEL 7, 8, 9 y 10, además de los contenedores basados en imágenes RHEL o UBI y los productos que se apoyan en RHEL; Red Hat está publicando las actualizaciones de forma progresiva (RHSB-2026-013) y los contenedores deben reconstruirse cuando se actualicen las imágenes base. AlmaLinux ha publicado paquetes corregidos.
- Si se usa el repositorio rpms.remirepo.net: php.net advirtió de que ese repositorio no tendría actualizaciones el 21 de octubre y recomienda pasar a los paquetes de la distribución o compilar desde el código fuente.
- Windows: los binarios corregidos están en la página de descargas de php.net.
- PHP 8.1, 8.0 y 7.4: el proyecto no publicará versiones oficiales. El equipo de seguridad de PHP ha facilitado parches en código fuente para esas ramas; si no, recurrir a un proveedor LTS o migrar a una versión con soporte. PHP 7.3 y anteriores (incluido PHP 5) no tienen parche, salvo mediante el soporte extendido de algunas distribuciones (por ejemplo, Ubuntu Pro).
4. Actualizar y reiniciar los servicios
- Debian y Ubuntu: sudo apt update && sudo apt upgrade
- RHEL y derivadas: sudo dnf update 'php*'
- Reiniciar todos los servicios que usan PHP; si no, el binario antiguo sigue en memoria. Por ejemplo: sudo systemctl restart php8.3-fpm o sudo systemctl restart apache2 (en RHEL: php-fpm y httpd).
- Contenedores: actualizar la imagen base a una etiqueta con la versión corregida y reconstruir; las imágenes ya construidas no se actualizan solas.
- Después de actualizar, repetir la comprobación del paso 3.
5. Medidas temporales (si no es posible actualizar de inmediato)
Según php.net, estas medidas reducen algunas vías de ataque concretas, pero no hacen segura la instalación. Hay que actualizar lo antes posible.
- CVE-2026-109618:
· memory_limit=-1, fijado de forma que las aplicaciones no puedan cambiarlo (por ejemplo, php_admin_value en el pool de FPM o en la configuración de Apache). Comprobar que ninguna otra configuración vuelve a poner un límite finito. Para limitar la memoria, usar un límite de contenedor o cgroup; no usar RLIMIT_AS ni RLIMIT_DATA, porque pueden provocar el fallo vulnerable.
· post_max_size = 8M si no se suben ficheros; si es necesario, post_max_size = 32M, con upload_max_filesize por debajo de post_max_size.
· Límites en el servidor web o proxy: tamaño de la petición, número de campos, número de partes multipart, número de cabeceras y profundidad de anidamiento. Deben aplicarse también a peticiones sin un Content-Length utilizable.
- CVE-2026-109619:
· session.upload_progress.enabled=0 en php.ini o en el pool de FPM, y reiniciar todos los workers. No sirve hacerlo con ini_set() ni con .user.ini. Solo bloquea una vía demostrada de CVE-2026-109619: no protege frente a CVE-2026-109618 ni frente a otras variantes.
· PHP 8.5: fatal_error_backtraces=0, y reiniciar todos los workers.
· Eliminar los ajustes no válidos u obsoletos que se aplican en cada petición si generan diagnósticos antes de la inicialización. Ocultar los diagnósticos con error_reporting, display_errors o @ no sirve.
· Corregir los errores fatales y los agotamientos de tiempo de ejecución que pueda provocar un atacante (en callbacks, procesamiento de subidas o importaciones, y limpieza).
- Recomendación de Cyberzaintza: hasta actualizar, aislar el servidor de Internet o restringir el acceso.
6. Detectar señales de explotación
Por ahora no hay IoC oficiales. Las señales siguientes son las que recomiendan los fabricantes (Datadog, Tanium):
- Procesos de shell (sh, bash) u otros comandos lanzados por el servidor web o los workers de PHP (usuarios www-data, apache, nginx o php-fpm). Según Datadog, esta señal permite detectar la explotación de ambas vulnerabilidades. Para ver el árbol de procesos: ps -ef --forest
- Errores de agotamiento de memoria al inicio de las peticiones en los logs de PHP (por ejemplo, «Allowed memory size of ... bytes exhausted»), sobre todo junto a peticiones POST grandes.
- Peticiones POST o multipart inusuales o muy grandes en los logs de acceso, contra cualquier fichero .php (incluso scripts triviales).
- Caídas inexplicables de workers (en el log de PHP-FPM, por ejemplo, «exited on signal 11»). Tener en cuenta que una explotación con éxito no tiene por qué tumbar el worker: que no haya caídas no significa que no haya habido ataque.
- Comprobaciones posteriores a una posible explotación (buenas prácticas):
· Ficheros nuevos o modificados en los directorios web, no solo .php: find /var/www -type f -ctime -10 (adaptar la ruta). Se usa -ctime para detectar cambios aunque se haya alterado la fecha con touch; tener en cuenta que las actualizaciones también modifican ficheros.
· Conexiones salientes inesperadas desde el servidor web, tareas cron nuevas y usuarios o claves SSH nuevos.
- No descargar PoC publicadas en GitHub para hacer pruebas: las PoC falsas de CVE mediáticas contienen malware con frecuencia (Tanium).
7. Si se sospecha que ha habido un compromiso
- Actualizar no elimina un compromiso previo: el atacante puede haber dejado puertas traseras.
- Aislar el servidor de la red, pero no apagarlo ni borrar nada: conservar los logs y las evidencias.
- Cambiar las credenciales accesibles desde el servidor (bases de datos, claves de API, ficheros de configuración).
- Notificarlo a Cyberzaintza: incidencias@cyberzaintza.eus o 900 104 891.
Referencias adicionales
- Aviso de seguridad - php.net
- Aviso de seguridad - GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- Aviso de seguridad - GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- Aviso de seguridad - The PHP Foundation
- Aviso de seguridad - Debian
- Aviso de seguridad - Ubuntu
- Aviso de seguridad - AlmaLinux
- Aviso de seguridad - Red Hat RHSB-2026-013
- Aviso de seguridad - Datadog Security Labs
- Aviso de seguridad - Tanium