21 octubre 2026
Noticias, Seguridad
9 minutos de lectura

PHP2Shell: qué distribuciones y paneles ya han parcheado PHP y cómo mitigar

Antonio

PHP publicó el 21/10/2026 las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen PHP2Shell, el nombre con el que se conocen dos vulnerabilidades críticas del intérprete (CVE-2026-109618 y CVE-2026-109619) que permiten ejecutar código en el servidor sin autenticación. Horas después, las principales distribuciones y algunos paneles de hosting empezaron a distribuir paquetes corregidos, aunque a ritmos muy distintos. Al mismo tiempo, varias empresas de seguridad informaban de intentos de explotación, así que el margen para actualizar es corto.

Las claves de PHP2Shell y sus parches en 30 segundos

PHP corrige PHP2Shell en 8.5.12, 8.4.27, 8.3.36 y 8.2.35; las ramas 8.1 y anteriores solo reciben backports de terceros.
Ubuntu, Debian 13, RHEL 9 (php:8.2), DirectAdmin y Plesk en Linux ya tienen paquetes corregidos.
AlmaLinux, CloudLinux y cPanel los estaban preparando; Remi no los tendría el mismo día.
Cloudflare, Patchstack y watchTowr hablan de ataques o intentos de explotación.
Las medidas temporales reducen el riesgo, pero solo actualizar lo elimina.

Los fallos los descubrieron Wiz Research, OpenAI Codex Security y la empresa Calif, y los coordinaron el equipo de seguridad de PHP y el equipo de Gemini de Google. Wiz ha montado una web propia, php2shell.com, con el resumen técnico y las recomendaciones. Su existencia se filtró el 20/10/2026, un día antes del parche, y los medios de este grupo lo han seguido desde entonces: en OpenSecurity se explicó cómo se filtraron las dos vulnerabilidades críticas de PHP antes del parche, en Administración de Sistemas se publicó una guía rápida para sysadmins y en WPDirecto se contó qué suponen estos fallos para WordPress. Hay también una versión en inglés para administradores en SystemAdministration.net.

Qué es PHP2Shell y a quién afecta

Las dos vulnerabilidades están en el propio PHP, no en las aplicaciones, de modo que un WordPress, un Drupal o una tienda bien mantenidos pueden ser vulnerables igual. Según el aviso de PHP, CVE-2026-109618 aparece cuando la gestión de falta de memoria interrumpe PHP con datos internos de la petición a medio inicializar, y la limpieza posterior los trata como válidos. CVE-2026-109619 se produce cuando un estado interno ligado a una petición sobrevive a la liberación de su memoria y una petición posterior en el mismo proceso lo reutiliza. Ambas tienen una puntuación de 9,2 sobre 10 en CVSS v4.0.

Afectan a todas las instalaciones de PHP que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP sitúa el riesgo más alto en mod_php, donde hay un exploit demostrado en el que una petición sin autenticar desencadena el ataque antes de que se ejecute ningún código de la aplicación (en Revista Cloud se explicaron las diferencias entre mod_php, CGI, FastCGI y FPM). Según php2shell.com, los investigadores demostraron ejecución remota de código previa a la autenticación en WordPress, Drupal y Joomla, y la web asegura que casi todas las versiones desde PHP 5.4 estaban afectadas por al menos uno de los fallos. Además de ejecutar código, un atacante podría leer memoria del proceso, con contraseñas, tokens o claves de API.

Red Hat da una valoración más contenida para su plataforma: clasifica el fallo como importante, no crítico, y sostiene que las instalaciones estándar de Red Hat Enterprise Linux usan PHP-FPM y no mod_php, y que en ese caso la ejecución remota es difícil en la práctica porque suele requerir un comportamiento no habitual de la aplicación.

Ataques: lo que dicen Cloudflare, Patchstack y watchTowr

Cloudflare afirma que vio tráfico de ataque contra sus clientes después de la filtración y antes de que existiera el parche, y que los atacantes modificaban las cargas para intentar esquivar sus reglas. Patchstack informó de incidentes de explotación activa confirmados desde las 07:34 UTC del 21/10/2026, y watchTowr dice estar observando intentos de explotación de las dos CVE. Huntress, en cambio, no había detectado explotación en su base de clientes a media mañana del mismo día. El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) llegó a recomendar desconectar los sistemas que no pudieran protegerse. BleepingComputer cita una estimación de VirusTotal de más de 5,1 millones de servidores con PHP expuestos en Internet.

Distribuciones Linux: quién ha publicado ya los parches

PHP repartió los parches por adelantado a las distribuciones y a los proveedores de soporte extendido, pero no todos los publicaron a la vez. La situación al cierre de este artículo, el 21/10/2026, era esta:

Ubuntu: el aviso USN-8948-1 corrige PHP en Ubuntu 26.10, 26.04 LTS (PHP 8.5), 24.04 LTS (PHP 8.3) y 22.04 LTS (PHP 8.1). Ubuntu mantiene el número de versión original y aplica el arreglo como parche, así que hay que mirar la revisión del paquete (por ejemplo, 8.3.6-0ubuntu0.24.04.13 en 24.04), no lo que muestra php -v.
Debian: el aviso DSA-6574-1 actualiza php8.4 en Debian 13 (trixie) a 8.4.27-1~deb13u1. Para Debian 12 (bookworm), con PHP 8.2, el arreglo no figuraba aún en el seguimiento de seguridad.
Repositorio de Ondřej Surý (packages.sury.org y su PPA, muy usado en Debian y Ubuntu): ha publicado las versiones corregidas de 8.2 a 8.5 y backports para ramas antiguas, de PHP 8.1 a 5.6. Conviene leer el registro de cambios de esos backports antes de desplegarlos.
Red Hat Enterprise Linux: el aviso RHSA-2026:87072 actualiza el módulo php:8.2 de RHEL 9 a PHP 8.2.35. No había avisos publicados para el resto de flujos de PHP.
AlmaLinux: anunció que subiría los paquetes al repositorio de pruebas el mismo día, por delante de Red Hat, para los flujos 7.4 y 8.2 de AlmaLinux 8, para PHP 8.0, 8.2 y 8.3 en AlmaLinux 9 y para PHP 8.3 y 8.4 en AlmaLinux 10.
Repositorio de Remi (RHEL, AlmaLinux y Rocky): el propio aviso de PHP advierte de que no tendrá actualizaciones el 21/10/2026 y aconseja pasar a los paquetes de la distribución o compilar desde el código fuente.
CloudLinux: preparaba los paquetes alt-php y, mientras tanto, ha publicado el conjunto de reglas 8.83 de Imunify360, que bloquea la forma del exploit que circula y que la propia compañía presenta como parche virtual, no como solución.

Para quien compila PHP desde el código fuente sin un proveedor de soporte, el equipo de PHP ha publicado backports mínimos para 7.4, 8.0 y 8.1, ramas que ya no reciben actualizaciones oficiales. El aviso recuerda también que PHP 8.2 deja de tener soporte el 31/12/2026.

Paneles de hosting y plataformas gestionadas

Plesk: en Linux ya distribuye PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 por el sistema de actualizaciones habitual; las versiones para Windows y las compilaciones de 7.4, 8.0 y 8.1 estaban en desarrollo. El motor PHP del propio panel (sw-engine) también está afectado y Plesk prevé corregirlo con los hotfixes 18.0.80#11 y 18.0.81#4.
DirectAdmin: ha publicado en los canales current y stable una compilación que actualiza PHP 8.2 a 8.5 y añade parches para 8.1, 8.0 y 7.4. Se instala con da update y da build php si no está activada la actualización automática de CustomBuild. Su equipo reconoce que PHP 8.1 no compila bien en algunos sistemas con el parche y que de 5.6 a 7.3 aún no hay parches.
cPanel: según el seguimiento en directo de Precursor Security, preparaba las actualizaciones de ea-php74 a ea-php85, y las versiones antiguas podrían cubrirse con los backports de CloudLinux.
LiteSpeed y OpenLiteSpeed: PHP incluye LiteSpeed entre los entornos afectados. Sus paquetes lsphp se actualizan desde el repositorio de LiteSpeed y después hay que reiniciar los procesos lsphp. Al cierre de este artículo no constaba un comunicado público de la compañía con versiones corregidas.
RunCloud: al cierre tampoco constaba un aviso público. Los usuarios deben comprobar en el panel qué versión de PHP tiene cada servidor y aplicar las actualizaciones en cuanto aparezcan.
Google Cloud: App Engine estándar con PHP 8.2 o superior se ha actualizado solo, igual que Cloud Run y Cloud Run functions si tienen activadas las actualizaciones automáticas de la imagen base. App Engine flexible, GKE y los contenedores propios requieren reconstruir y volver a desplegar.
Imágenes Docker: reiniciar un contenedor no sirve; hay que descargar la imagen corregida o reconstruir con docker build --pull y volver a desplegar.

En todos los casos, el paso que más se olvida es reiniciar: los procesos de PHP-FPM, Apache con mod_php o lsphp que ya estaban en marcha siguen usando el binario vulnerable hasta que se reinician.

Cómo mitigar mientras se actualiza

El aviso de PHP y php2shell.com proponen varias medidas para quien no pueda actualizar de inmediato, con una advertencia clara: reducen la exposición, pero no dejan la instalación a salvo.

Para CVE-2026-109618: fijar memory_limit=-1, preferiblemente con php_admin_value en el pool de PHP-FPM o en la configuración de Apache, y comprobar que nada vuelve a imponer un límite. Como el proceso deja de estar limitado, conviene contenerlo con un límite de contenedor o de cgroup v2 (memory.max). No hay que usar RLIMIT_AS ni RLIMIT_DATA, que pueden provocar justo el fallo vulnerable.
Bajar post_max_size a 8M si la web no recibe archivos o a 32M si los recibe, con upload_max_filesize por debajo, y limitar en el servidor web o el proxy el tamaño de las peticiones y el número de campos y partes multipart.
Para CVE-2026-109619: desactivar session.upload_progress.enabled en el php.ini, en el pool de FPM o en la configuración del servidor, y reiniciar todos los procesos. No sirve hacerlo con ini_set() ni con .user.ini.
En PHP 8.5, fijar fatal_error_backtraces=0. Ocultar errores con display_errors, error_reporting o @ no ayuda.
Activar las reglas de un cortafuegos de aplicaciones web. Cloudflare las aplica desde las 03:02 UTC del 21/10/2026 en todos sus planes, incluido el gratuito, con las reglas «Generic Rules – Anomalous Execution» y una regla de bloqueo por defecto para firmas de alta confianza; en los planes de pago hay que comprobar que el conjunto gestionado está en modo bloqueo.

; Medidas temporales (php.ini o pool de PHP-FPM)
session.upload_progress.enabled = 0
post_max_size = 8M
; En el pool: php_admin_value[memory_limit] = -1
; Solo PHP 8.5:
fatal_error_backtraces = 0

Para detectar un posible compromiso, Huntress recomienda vigilar procesos hijos sospechosos de PHP-FPM, php-cgi o Apache, como shells, curl, wget o comandos de reconocimiento como whoami o uname, además de archivos nuevos en la raíz web, tareas cron y cuentas creadas recientemente. watchTowr aconseja guardar los registros y las configuraciones antes de tocar nada si hay sospechas.

Preguntas frecuentes

¿Qué versiones de PHP corrigen PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21/10/2026. Las ramas 8.1 y anteriores solo tienen backports de distribuciones, proveedores de soporte extendido o parches mínimos para compilar desde el código fuente.

¿Está parcheado Ubuntu contra PHP2Shell?

Sí. El aviso USN-8948-1 corrige PHP en Ubuntu 26.10, 26.04 LTS, 24.04 LTS y 22.04 LTS. Ubuntu conserva el número de versión, así que hay que comprobar la revisión del paquete, no php -v.

¿Plesk y DirectAdmin tienen ya PHP corregido?

Plesk distribuye en Linux las versiones 8.2.35 a 8.5.12 y prepara las de Windows y las ramas antiguas. DirectAdmin ha publicado una compilación con PHP 8.2 a 8.5 actualizado y parches para 8.1, 8.0 y 7.4.

¿Basta con desactivar session.upload_progress?

No. Solo bloquea una de las vías confirmadas de CVE-2026-109619. PHP insiste en que actualizar es la única solución completa y en que hay que reiniciar todos los procesos de PHP después.

Fuentes: