El 21 de octubre de 2026, PHP divulgó dos vulnerabilidades críticas en el runtime del lenguaje. Identificadas como CVE-2026-109618 y CVE-2026-109619, los fallos recibieron CVSS 9.2 y pueden permitir la ejecución remota de código sin autenticación en servidores vulnerables. Como el problema está en el propio PHP, la corrección definitiva requiere actualizar el runtime.
El equipo de seguridad de Azion creó un hotfix contra PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Está disponible en Azion Marketplace como una function que puedes aplicar al Firewall de cualquier aplicación.
El hotfix evalúa cada solicitud antes de que llegue a tu origen y bloquea los vectores de ataque confirmados por el comunicado oficial de PHP. No requiere acceso al servidor ni reiniciar workers.
Los dos fallos tienen CVSS 9.2 y permiten ejecución remota de código sin autenticación, antes de que se ejecute una sola línea de tu aplicación. El hotfix cierra esos caminos antes del origen y le da tiempo a tu equipo para aplicar la corrección definitiva: actualizar PHP.
Qué cubre el hotfix
| Vector de ataque | Estado | Cómo se mitiga |
|---|---|---|
| CVE-2026-109619 por la ruta de sesión (upload progress), confirmado por PHP | Mitigado en el Firewall | Bloqueo total del campo PHP_SESSION_UPLOAD_PROGRESS, incluidas variaciones y disfraces |
| CVE-2026-109618, agotamiento de memoria al armar la solicitud | Mitigado en el Firewall | Límites oficiales de PHP para tamaño del body, campos, partes del multipart, headers y profundidad de arrays |
Envíos chunked sin Content-Length usados para eludir límites | Mitigado en el Firewall | Medición del tamaño real del body |
| Técnica de upload progress + LFI → RCE (Exploit-DB 50156) | Mitigado en el Firewall | Mismo bloqueo del campo de upload progress |
| Solicitudes malformadas o ilegibles | Bloqueo preventivo | Se bloquea el multipart sin boundary o el body ilegible |
El hotfix es la primera línea de defensa. La corrección definitiva sigue siendo actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35. La actualización también cierra variantes de la CVE-2026-109619 originadas dentro del servidor, como errores fatales y timeouts.
Qué sabemos sobre las vulnerabilidades
PHP2Shell reúne dos vulnerabilidades críticas en el runtime de PHP, ambas evaluadas con CVSS v4.0 9.2. Solicitudes HTTP especialmente preparadas pueden explotar fallos en la gestión de memoria para causar indisponibilidad, exponer datos procesados por el servidor o ejecutar código de forma remota sin autenticación.
Antes de la divulgación coordinada, los identificadores de las CVE comenzaron a circular públicamente y se publicó por error un video de proof of concept. Cloudflare y Fastly también identificaron herramientas y tráfico que intentaban explotar los fallos en las horas previas a la publicación de los advisories. Estos registros demuestran actividad maliciosa, pero no significan que todos los intentos hayan resultado en una explotación exitosa.
Las dos vulnerabilidades aparecen cuando una solicitud se interrumpe en un punto en el que el estado interno de PHP aún no se ha inicializado o finalizado de forma segura:
| CVE | Nombre | Qué ocurre |
|---|---|---|
| CVE-2026-109618 | RCE por corrupción por falta de memoria (OOM) | El manejo de falta de memoria interrumpe PHP mientras los datos internos de la solicitud aún tienen la inicialización incompleta. Durante la limpieza, PHP trata esos datos inválidos como válidos, lo que abre el camino a la ejecución de código. |
| CVE-2026-109619 | RCE por estado global obsoleto | Un estado interno de la solicitud sobrevive después de que se liberó su memoria. Una solicitud posterior, en el mismo worker, puede usar ese estado antes del reinicio normal. |
Todas las instalaciones que atienden solicitudes web deben actualizarse, incluidos los entornos con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. La posibilidad y la forma de explotación varían según el servidor, la configuración y el flujo de la aplicación. El riesgo se considera mayor en mod_php, para el que se demostró un camino de RCE sin autenticación.
Como los fallos están en el runtime, actualizar solo el código de la aplicación, el framework o los plugins no resuelve el problema. La única corrección completa es instalar una versión corregida de PHP. Los controles en el Firewall ayudan a reducir la exposición a vectores conocidos, pero funcionan como una capa adicional de protección.
Cómo funciona el hotfix
PHP2Shell explota el momento en que PHP arma la solicitud, antes de que se ejecute cualquier línea de la aplicación. Por eso, el equipo de seguridad de Azion diseñó el hotfix para impedir que la solicitud maliciosa llegue a PHP.
Se ejecuta en el Firewall, evalúa cada solicitud y toma exactamente una decisión: permitir o bloquear. El algoritmo sigue seis principios.
Una decisión por solicitud
Cada solicitud recibe una sola respuesta. Una vez que el hotfix decide, no se aplica ninguna otra decisión.
Si el análisis termina sin respuesta por cualquier motivo, una red de seguridad aplica la decisión predeterminada del modo configurado.
Costo proporcional al riesgo
La inspección va de la etapa más ligera a la más completa, y la mayor parte del tráfico se decide sin abrir el body:
- Conteo de headers, parámetros del query string y cookies, y medición de la profundidad de arrays en los nombres, como
a[b][c]. Aplica a todas las solicitudes. - Liberación de solicitudes sin body, como GET, HEAD y OPTIONS.
- Bloqueo por el tamaño declarado en
Content-Length, cuando supera el límite. - Liberación de JSON, XML y similares con tamaño válido, que PHP no convierte en variables.
- Lectura del body solo en multipart, urlencoded y envíos sin tamaño declarado.
Medir lo que llega, no lo que se declara
Un atacante puede omitir Content-Length y enviar el body en partes (chunked) para eludir los límites. En esos casos, el hotfix lee una copia del body y mide el tamaño real, byte por byte. El contenido original llega intacto al origen.
Detectar el campo, no la grafía
La ruta confirmada de la CVE-2026-109619 pasa por el campo PHP_SESSION_UPLOAD_PROGRESS. El hotfix busca ese nombre en cualquier declaración de campo del multipart: con comillas dobles, comillas simples o sin comillas, con espacios extra y en cualquier combinación de mayúsculas y minúsculas.
La búsqueda recorre el body completo, y no solo las partes que un parser consideraría válidas. Así, las diferencias entre parsers no abren una brecha.
Ante la duda, bloquear
Un multipart sin boundary válido, un body que no se puede leer o un error inesperado durante el análisis terminan en bloqueo. La política es fail-closed: una solicitud que el hotfix no puede evaluar no llega a un PHP vulnerable.
Límites oficiales de PHP
Los límites predeterminados siguen las recomendaciones del comunicado oficial de PHP y se pueden ajustar por aplicación:
| Regla | Límite predeterminado | Base |
|---|---|---|
| Body de upload (multipart) | 32 MB | post_max_size = 32M con uploads |
| Body de los demás tipos, incluidos JSON y XML | 8 MB | post_max_size = 8M sin uploads |
| Campos en query, cookies y formulario | 1,000 | Valor predeterminado de PHP para max_input_vars |
| Profundidad de arrays en nombres de campos | 32 | Por debajo del valor predeterminado de PHP para max_input_nesting_level (64) |
| Partes en el multipart | 500 | Límite recomendado por PHP |
| Headers en la solicitud | 100 | Límite recomendado por PHP |
Campo PHP_SESSION_UPLOAD_PROGRESS | Bloqueo total | Ruta de sesión confirmada de la CVE-2026-109619 |
Cada detección registra el motivo, la CVE relacionada, el valor medido frente al límite (por ejemplo, 501 partes contra 500), la IP, el host y el path. El contenido enviado por el usuario no se guarda.
Cómo aplicar el hotfix
El hotfix está disponible en Azion Marketplace y se puede aplicar al Firewall de cada aplicación en pocos minutos. Te recomendamos empezar en modo de observación, para medir su comportamiento con tráfico real antes de bloquear:
- Instala el hotfix PHP2Shell desde Azion Marketplace.
- Aplica el hotfix al Firewall de la aplicación, con una regla que cubra todas las rutas del dominio (por ejemplo, URI comienza con
/), y no solo la página de inicio. - Activa el modo de observación y revisa las detecciones en Real-Time Events durante algunas horas.
- Si hay detecciones en tráfico legítimo, ajusta los límites de la configuración.
- Activa el modo de protección para bloquear las solicitudes maliciosas.
| Modo | Comportamiento |
|---|---|
| Observación | Registra cada detección y permite la solicitud |
| Protección (predeterminado) | Registra cada detección y bloquea la solicitud |
Cada detección llega a Real-Time Events con la etiqueta PHP2SHELL, el motivo y la CVE relacionada:
| Motivo | Significado | CVE |
|---|---|---|
UPLOAD_PROGRESS_FIELD | Campo PHP_SESSION_UPLOAD_PROGRESS en el multipart | CVE-2026-109619 |
BODY_TOO_LARGE_DECLARED | Content-Length por encima del límite | CVE-2026-109618 |
BODY_TOO_LARGE_ACTUAL | Body real por encima del límite, por ejemplo en envíos chunked | CVE-2026-109618 |
TOO_MANY_HEADERS, TOO_MANY_QUERY_VARS, TOO_MANY_COOKIES, TOO_MANY_BODY_VARS | Cantidad por encima del límite | CVE-2026-109618 |
TOO_MANY_PARTS | Partes del multipart por encima del límite | CVE-2026-109618 |
NESTING_TOO_DEEP | Profundidad de array por encima del límite | CVE-2026-109618 |
MULTIPART_NO_BOUNDARY, BODY_READ_ERROR | Solicitud malformada o ilegible | Preventivo |
Algunos escenarios legítimos pueden requerir un ajuste fino:
- API que reciben JSON o XML de más de 8 MB: aumenta el límite de body de los demás tipos.
- Uploads de más de 32 MB, como videos y respaldos: aumenta el límite de body de upload.
- Paneles administrativos con formularios de más de 1,000 campos: aumenta el límite de campos.
Actualiza PHP y mantén el hotfix activo
La estrategia más segura es la defensa en profundidad: actualizar PHP a una versión corregida y mantener el hotfix aplicado antes, durante y después de la actualización.
| Capa | Acción |
|---|---|
| 1. Corrección | Actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o aplicar el paquete corregido de la distribución. PHP 8.1 y anteriores no reciben actualización oficial, pero hay correcciones mínimas en el código fuente para 7.4, 8.0 y 8.1. Si un proveedor de hosting gestiona tu PHP, solicita la actualización. |
| 2. Firewall (Azion) | Mantener el hotfix aplicado al Firewall de todas las aplicaciones que usan PHP. |
| 3. Configuración de PHP (CVE-2026-109619) | Definir session.upload_progress.enabled=0 en php.ini o en el pool de FPM y reiniciar todos los workers, sin usar ini_set() ni .user.ini. En PHP 8.5, definir también fatal_error_backtraces=0. |
| 4. Configuración de PHP (CVE-2026-109618) | Usar un post_max_size bajo (8M sin uploads, 32M con uploads) y limitar la memoria por contenedor o cgroup. |
| 5. Detección en el host | Alertar cuando php-fpm, php-cgi, httpd o apache2 inicien shells, intérpretes o herramientas como curl, wget y nc. |
El equipo de seguridad de Azion sigue evolucionando sus mecanismos de defensa para responder a nuevas amenazas, incluidos los ataques de día cero.
Instala el hotfix desde Azion Marketplace o habla con un experto de Azion para proteger tus aplicaciones PHP.
Preguntas frecuentes
¿Actualizar el código de la aplicación o los plugins resuelve PHP2Shell? No. Los fallos están en el runtime de PHP, así que solo la actualización de PHP corrige el problema. El hotfix bloquea los vectores confirmados mientras tanto.
¿El hotfix reemplaza la actualización de PHP? No. Es la primera línea de defensa. La actualización también cierra variantes de la CVE-2026-109619 originadas dentro del servidor, como errores fatales y timeouts.
¿El hotfix aumenta la latencia? El impacto es mínimo. La inspección va de la etapa más ligera a la más completa, y las solicitudes sin body, o con JSON y XML de tamaño válido, se liberan sin leer el body.
¿El hotfix altera el contenido enviado al origen? No. Lee una copia del body y el contenido original llega intacto. Los registros no guardan el contenido enviado por el usuario.
Referencias
- Comunicado de seguridad de PHP, 21 de octubre de 2026
- CVE-2026-109618: GHSA-w8hw-w9fx-j79w (PHP Security Advisories)
- CVE-2026-109619: GHSA-6wmf-4rv5-p3rp (PHP Security Advisories)
- Sansec: PHP2Shell
- Exploit-DB 50156: PHP_SESSION_UPLOAD_PROGRESS Session Data Injection
