El 21/10/2026, PHP lanzó actualizaciones para las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 que corrigen PHP2Shell, el nombre dado a dos vulnerabilidades críticas en el intérprete (CVE-2026-109618 y CVE-2026-109619) que permiten ejecutar código en el servidor sin necesidad de autenticación. Horas después, las principales distribuciones y algunos paneles de hosting comenzaron a distribuir parches corregidos, aunque a velocidades distintas. Simultáneamente, varias empresas de seguridad alertaron sobre intentos de explotación, por lo que el margen para actualizar es muy ajustado.
Resumen en 30 segundos: PHP2Shell y sus parches
- PHP corrige PHP2Shell en las versiones 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 disponen de paquetes corregidos.
- AlmaLinux, CloudLinux y cPanel estaban preparando las actualizaciones; Remi aún no las tendría en ese mismo día.
- Cloudflare, Patchstack y watchTowr reportan ataques o intentos de explotación.
- Las medidas temporales ayudan a reducir el riesgo, pero solo la actualización completa elimina la vulnerabilidad.
Estos fallos fueron descubiertos por Wiz Research, OpenAI Codex Security y la empresa Calif, coordinados por el equipo de seguridad de PHP y el equipo Gemini de Google. Wiz creó una web propia, php2shell.com, con el análisis técnico y sus recomendaciones. La filtración de este hallazgo ocurrió el 20/10/2026, un día antes del lanzamiento del parche, y los medios de comunicación especializados lo han seguido desde entonces: en OpenSecurity se explicó cómo se filtraron las vulnerabilidades críticas en PHP antes del parche; en Administración de Sistemas se publicó una guía rápida para administradores y en WPDirecto se abordó su impacto en WordPress. También existe una versión en inglés en SystemAdministration.net dirigida a administradores.
¿Qué es PHP2Shell y quiénes están afectados?
Las dos vulnerabilidades afectan directamente al núcleo de PHP, no a las aplicaciones. Por ello, incluso sitios bien mantenidos en WordPress, Drupal o tiendas en línea pueden ser vulnerables. Según el aviso de PHP, CVE-2026-109618 se produce cuando la gestión de memoria insuficiente interrumpe PHP enviando datos internos de la petición en estado parcialmente inicializado, y la limpieza posterior los marca como válidos; CVE-2026-109619 sucede cuando un estado interno ligado a una petición sobrevive a la liberación de memoria y una petición subsiguiente en el mismo proceso la reutiliza. Ambas vulnerabilidades tienen una puntuación de 9.2 sobre 10 en CVSS v4.0.
Afectan a cualquier instalación de PHP que sirva peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto está en mod_php, donde ya se ha demostrado un exploit que puede activar el ataque sin necesidad de autenticación, en una petición no autenticada (en esto se profundizó en Revista Cloud). Según php2shell.com, investigadores demostraron ejecución remota de código en WordPress, Drupal y Joomla antes del parche. La web asegura que casi todas las versiones desde PHP 5.4 estaban vulnerables al menos en uno de los fallos. Además de ejecutar código, un atacante podría leer memoria del proceso, obteniendo contraseñas, tokens o claves API.
Red Hat ofrece una valoración menos crítica, calificando el fallo como importante y no como crítico. Considera que las instalaciones de Red Hat Enterprise Linux, que habitualmente usan PHP-FPM y no mod_php, dificultan la explotación remota en la práctica, ya que generalmente requiere un comportamiento no habitual de la aplicación.
¿Qué dicen Cloudflare, Patchstack y watchTowr sobre los ataques?
Cloudflare reportó tráfico de ataque dirigido a sus clientes desde la filtración y antes de que existiera un parche, con atacantes modificando cargas útiles para evadir reglas de detección. Patchstack comunicó incidentes de explotación activa desde las 07:34 UTC del 21/10/2026, mientras que watchTowr observa intentos de explotación de las CVE. En contraste, Huntress no detectó explotación en su base de clientes a media mañana de ese mismo día. El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) recomendó desconectar los sistemas no protegidos. BleepingComputer cita una estimación de VirusTotal que señala más de 5,1 millones de servidores con PHP expuestos en internet.
¿Qué distribuciones Linux han publicado ya los parches?
PHP distribuyó los parches a través de distribuciones y proveedores de soporte extendido con antelación, aunque no todos los publicaron simultáneamente. Al cierre de este artículo, 21/10/2026, la situación es la siguiente:
- 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 mismo número de versión en el paquete y aplica el parche como una revisión, por lo que hay que revisar la versión del paquete (por ejemplo, 8.3.6-0ubuntu0.24.04.13 en 24.04), no solo ejecutar
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 parche aún no aparece en la actually en seguimiento de seguridad.
- Repositorio de Ondřej Surý: Publica versiones corregidas desde 8.2 a 8.5 y backports para versiones antiguas (de PHP 5.6 a 8.1). Es recomendable revisar los cambios antes de desplegar esos backports.
- Red Hat Enterprise Linux: El aviso RHSA-2026:87072 actualiza PHP en RHEL 9 a PHP 8.2.35, específicamente el módulo php:8.2. No hay anuncios relativos para otros flujos de PHP aún.
- AlmaLinux: Anunció que subirá los paquetes al repositorio de pruebas el mismo día, por delante de Red Hat, para los flujos 7.4 y 8.2 en AlmaLinux 8, y para PHP 8.0, 8.2 y 8.3 en AlmaLinux 9, además de PHP 8.3 y 8.4 para AlmaLinux 10.
- Repositorio de Remi: El aviso de PHP advierte que no tendrá actualizaciones el 21/10/2026 y recomienda pasar a los paquetes oficiales de la distribución o compilar desde el código fuente.
- CloudLinux: Está preparando los paquetes alt-php y, de momento, ha publicado las reglas 8.83 de Imunify360, que bloquean formas conocidas del exploit, presentándose como un parche virtual, no definitivo.
Para quienes compilan PHP desde el código y no tienen soporte externo, el equipo de PHP ha publicado backports mínimos para las ramas 7.4, 8.0 y 8.1, que ya no reciben actualizaciones oficiales. Además, recuerdan que PHP 8.2 dejará de tener soporte el 31/12/2026.
Paneles de hosting y plataformas gestionadas
- Plesk: Para Linux, ya distribuye PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 mediante su sistema habitual de actualización; las versiones para Windows y compilaciones para PHP 7.4, 8.0 y 8.1 están en desarrollo. El motor PHP interno del panel (sw-engine) también está afectado y Plesk prevé corregirlo con hotfixes 18.0.80#11 y 18.0.81#4.
- DirectAdmin: Ha lanzado una compilación en canales current y stable que actualiza PHP 8.2 a 8.5 y aporta parches para 8.1, 8.0 y 7.4. La instalación se realiza con
da updateyda build phpsi no se ha activado la actualización automática con CustomBuild. Su equipo indica que PHP 8.1 puede no compilar correctamente en algunos sistemas con los parches, y que en versiones anteriores (de 5.6 a 7.3) todavía no hay actualizaciones. - cPanel: Según información en tiempo real de Precursor Security, está preparando actualizaciones para migrar de ea-php74 a ea-php85. Las versiones antiguas podrían mantenerse mediante backports de CloudLinux.
- LiteSpeed y OpenLiteSpeed: PHP se incluye en estos entornos y sus paquetes lsphp se actualizan desde el repositorio oficial de LiteSpeed. Tras la actualización, es necesario reiniciar los procesos lsphp. Hasta ahora, no hay un anuncio oficial con versiones corregidas.
- RunCloud: También se desconoce por completo en este momento. Es importante verificar en el panel la versión de PHP y aplicar los parches en cuanto estén disponibles.
- Google Cloud: App Engine en modo estándar con PHP 8.2 o superior se actualiza automáticamente, al igual que Cloud Run y Cloud Functions si tienen activadas actualizaciones automáticas. Para App Engine flexible, GKE y otros contenedores, será necesario reconstruir y desplegar de nuevo.
- Imágenes Docker: Reinstalar un contenedor no es suficiente; hay que descargar la imagen corregida o reconstruirla con
docker build --pully volver a desplegar.
En todos los casos, uno de los pasos que suele olvidarse es reiniciar los procesos PHP-FPM, Apache con mod_php o lsphp, ya que las instancias en ejecución continúan operando con la versión vulnerable hasta que se reinician.
Medidas temporales para mitigar mientras se actualiza
El anuncio de PHP y php2shell.com sugieren varias acciones para quienes no puedan actualizar inmediatamente, advirtiendo claramente que estas reducen el riesgo pero no dejan la instalación completamente segura:
- Para CVE-2026-109618: establecer
memory_limit=-1, preferentemente usandophp_admin_valueen pools de PHP-FPM o en la configuración de Apache, asegurando que nada vuelva a imponer un límite. Como el proceso puede no tener límite, es recomendable restringirlo mediante contenedores o cgroups v2 (memory.max). Evitar usarRLIMIT_ASoRLIMIT_DATA, ya que pueden activar el vulnerabilidad. - Reducir
post_max_sizea 8M si la web no recibe archivos, o a 32M si sí los recibe, manteniendoupload_max_filesizepor debajo, y limitar en el servidor o proxy el tamaño de las peticiones, así como el número de campos o partes en multipart. - Para CVE-2026-109619: desactivar
session.upload_progress.enabledenphp.ini, en el pool de FPM o en la configuración del servidor, y reiniciar todos los procesos. No basta con usarini_set()ni modificar.user.ini. - En PHP 8.5, establecer
fatal_error_backtraces=0. Ocultar errores mediantedisplay_errorsoerror_reportingno es suficiente y puede empeorar la seguridad. - Activar reglas en un cortafuegos de aplicaciones web. Cloudflare ya las aplica desde las 03:02 UTC del 21/10/2026, incluyendo las reglas «Generic Rules – Anomalous Execution» y un bloqueo predeterminado basado en firmas de confianza elevada. En planes de pago, se debe verificar que el modo de manejo de reglas está en modo de 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 = 0Para detectar posibles compromisos, Huntress recomienda vigilar procesos sospechosos como shells, curl, wget o comandos de reconocimiento (whoami, uname), además de archivos nuevos en la raíz web, tareas cron y cuentas que se creen de manera inusual. watchTowr aconseja guardar registros y configuraciones antes de hacer cambios si hay indicios de compromiso.
Preguntas frecuentes
¿Qué versiones de PHP corrigen PHP2Shell?
Las versiones 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 reciben backports de distribuciones, soporte extendido o parches mínimos para compilación desde fuente.
¿Está Ubuntu parcheado 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 mantiene el mismo número de versión del paquete, por lo que es necesario revisar la revisión y no solo la salida de php -v.
¿Tanto Plesk como DirectAdmin disponen ya de PHP corregido?
Plesk distribuye en Linux las versiones 8.2.35 a 8.5.12 y está preparando versiones para Windows y versiones antiguas. DirectAdmin ha publicado una compilación con PHP 8.2 a 8.5 actualizados y parches para 8.1, 8.0 y 7.4.
¿Basta con desactivar session.upload_progress?
No. Esto solo bloquea una de las vías explotadas para CVE-2026-109619. La recomendación de PHP es actualizar siempre, además de reiniciar los procesos.
Fuentes:
- PHP2Shell (Wiz Research, OpenAI Codex Security y Calif)
- PHP: aviso de vulnerabilidad emitido el 21/10/2026
- PHP: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- PHP: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- OpenSecurity: PHP corrige hoy dos fallos críticos filtrados antes del parche
- Administración de Sistemas: guía rápida para sysadmins antes del parche
- WPDirecto: fallos críticos en PHP y su impacto en WordPress
- SystemAdministration.net: Guía de fallos críticos en PHP para sysadmins
- Ubuntu: USN-8948-1, vulnerabilidades en PHP
- Debian: DSA-6574-1, php8.4
- Red Hat: RHSA-2026:87072, php:8.2
- Red Hat: CVE-2026-109618
- AlmaLinux: php2shell, parches en desarrollo
- LinuxCompatible: Sury.org publica actualizaciones de PHP 5.6 a 8.5
- CloudLinux: reglas Imunify360 8.83
- Plesk: CVE-2026-109618 y CVE-2026-109619 en PHP de Plesk
- DirectAdmin: foro, actualizaciones críticas en PHP
- Precursor Security: seguimiento en vivo de PHP2Shell
- Google Cloud: respuesta a CVE-2026-109618 y CVE-2026-109619
- Cloudflare: protecciones WAF contra php2shell
- Mattias Geniar: cómo aplicar los parches
- BleepingComputer: parches de emergencia para PHP2Shell
- watchTowr: exploitan ejecución remota de código en PHP2Shell
- Patchstack: PHP vulnerable a RCE crítico, ataques en curso
- Huntress: respuesta rápida a PHP2Shell