De un Vistazo
¿Está usted afectado?
Si ejecuta PHP para atender solicitudes web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed) y su versión es anterior a 8.2.35, 8.3.36, 8.4.27 u 8.5.12, asuma que está afectado. Esto incluye las aplicaciones desarrolladas sobre PHP, como WordPress, Drupal, Magento y Laravel.
¿Está TR7 afectado?
No. Los appliances de TR7 no tienen ningún componente PHP que procese solicitudes HTTP, por lo que los productos de TR7 no están afectados por estas vulnerabilidades. Encontrará los detalles en ¿Está TR7 Afectado?.
Qué hacer ahora
- Actualice PHP en sus servidores de aplicaciones web y reinicie todos los workers de PHP.
- Aplique en esos servidores los ajustes temporales de PHP que se indican más abajo si no puede actualizar hoy.
- Hasta que se complete la actualización, aplique los ajustes de protección esencial en TR7 WAF-WAAP; poner sus aplicaciones PHP en Blocking mode es el primero de ellos.
Datos Clave
| ID del aviso | TR7-SA-2026-001 |
|---|---|
| Nombre | PHP2Shell |
| CVE | CVE-2026-109618 (ejecución remota de código mediante corrupción por falta de memoria), CVE-2026-109619 (ejecución remota de código mediante estado global obsoleto) |
| Avisos oficiales | Comunicado del PHP Security Team GHSA-w8hw-w9fx-j79w (CVE-2026-109618) GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) |
| Gravedad | CVSS v4.0 9.2, Crítica (PHP Security Team) |
| Requiere autenticación | No |
| Versiones corregidas | PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 |
| Ramas anteriores | El PHP Security Team publicó backports del código fuente para PHP 7.4, 8.0 y 8.1. Las distribuciones de Linux proporcionan sus propios paquetes parcheados. |
| Explotación | Se están notificando intentos de explotación. A 22 de octubre de 2026 no se había confirmado públicamente ningún compromiso exitoso. |
| CISA KEV | No figura en el catálogo del 21 de octubre de 2026 |
Qué Ocurrió
- 20 de octubre de 2026 Los detalles de las vulnerabilidades se hicieron públicos antes de la publicación coordinada.
- 21 de octubre de 2026 El proyecto PHP publicó las versiones corregidas y los avisos GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp.
- 21-22 de octubre de 2026 Se notificaron intentos de explotación y apareció código público de prueba de concepto.
Cómo Funciona el Ataque
Ambas vulnerabilidades están en el propio PHP, no en el código de la aplicación. El ataque se produce mientras PHP todavía está leyendo la solicitud entrante, antes de que se ejecute una sola línea de su aplicación. Actualizar WordPress, un plugin o su propio código no lo corrige.
- CVE-2026-109618 aprovecha el momento en que PHP se queda sin memoria. Los atacantes envían solicitudes que obligan a PHP a usar mucha memoria mientras analiza datos de formularios y cargas de archivos, de modo que PHP se detiene en un estado inseguro.
- CVE-2026-109619 deja datos obsoletos en un worker de PHP después de una solicitud, y una segunda solicitud al mismo worker los utiliza. Una de las vías documentadas usa la función session upload progress de PHP, que está habilitada de forma predeterminada y se activa mediante un campo de formulario llamado
PHP_SESSION_UPLOAD_PROGRESS.
Dado que las solicitudes que transportan estos ataques son, en su mayoría, solicitudes multipart/form-data (carga de archivos), cuerpos de solicitud grandes y solicitudes repetidas, un firewall de aplicaciones web puede ver y restringir muchas de ellas. No puede ver lo que ocurre dentro de la memoria de PHP.
¿Está TR7 Afectado?
Estas vulnerabilidades se encuentran en la capa de gestión de solicitudes del propio PHP y afectan a los servidores de aplicaciones que ejecutan PHP. Los appliances de TR7 no tienen ningún componente PHP que procese solicitudes HTTP, por lo que los productos de TR7 no están afectados por estas vulnerabilidades.
Qué Debe Hacer Ahora
El trabajo se realiza en dos lugares: sus propios servidores de aplicaciones web que ejecutan PHP, y TR7 WAF-WAAP. Cada sección numera sus propios pasos.
En sus servidores
Paso 1: Actualice PHP en sus servidores de aplicaciones web (la única corrección completa)
- Actualice PHP en los servidores que ejecutan su aplicación web a 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o instale el paquete parcheado de su distribución de Linux. Los paquetes de las distribuciones suelen conservar el número de versión antiguo; busque los números de CVE en el registro de cambios del paquete.
- Reinicie todos los workers de PHP (pools de PHP-FPM, Apache, LiteSpeed, workers de larga ejecución). Los procesos en ejecución siguen usando el código antiguo hasta que se reinician.
- Vuelva a compilar las imágenes de contenedor que incluyen su propio PHP. Actualizar el host no actualiza el PHP que hay dentro de una imagen.
- PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto PHP. Planifique la migración a una rama con soporte.
Paso 2: Ajustes temporales de PHP en sus servidores de aplicaciones web (si no puede actualizar hoy)
Estos ajustes se realizan en la configuración de PHP del servidor que ejecuta su aplicación web (php.ini o los ajustes del pool de PHP-FPM). El PHP Security Team enumera estas medidas. Reducen la exposición a vías de ataque específicas, pero no hacen que una instalación sea segura.
| Ajuste | Finalidad |
|---|---|
session.upload_progress.enabled = 0 | Elimina la vía de session upload progress de CVE-2026-109619. Reinicie todos los workers. El PHP Security Team sugiere mantenerlo desactivado después de aplicar el parche si no lo necesita. |
fatal_error_backtraces = 0 (PHP 8.5) | Elimina la vía del backtrace de errores fatales |
post_max_size = 8M (sin cargas) o 32M (con cargas), con upload_max_filesize inferior | Reduce la memoria que un atacante puede obligar a PHP a utilizar |
memory_limit = -1, establecido con php_admin_value | Elimina el fallo controlable del límite de memoria. En ese caso, una sola solicitud puede consumir toda la memoria del servidor; utilice límites de contenedor o de cgroup, nunca RLIMIT_AS ni RLIMIT_DATA |
En TR7 WAF-WAAP
Si puede actualizar PHP de inmediato, esa es la verdadera corrección. Si no puede, hasta que se complete la actualización puede proteger sus aplicaciones PHP frente a estos ataques con los ajustes de seguridad que TR7 WAF-WAAP ya ofrece, sin ninguna actualización de TR7. Los tres ajustes del Paso 1 constituyen la protección esencial; las medidas adicionales del Paso 2 reducen aún más la superficie de ataque, así que elija las que se adapten a su aplicación. Aplique los ajustes en cada vService y pruébelos primero en un vService que no sea de producción.
Paso 1: Protección esencial
1.1 Ponga el WAF en Blocking mode
Un WAF que solo monitoriza no detiene un ataque. Cuando el WAF se habilita por primera vez, se inicia en Learning mode; Monitor mode solo registra. Para cada vService PHP, abra la pantalla WAF Mode y confirme que está en Blocking mode.
Precaución: Antes de cambiar, revise las exclusiones de firmas aprendidas en cada campo. Si las exclusiones de un campo superan el valor Max. owasp exclusions, la inspección de firmas se desactiva para ese campo.
1.2 Añada dos reglas personalizadas
En la pantalla Signature & Rule Library (WAF → Signature & Rule Library → Add), añada por separado las dos reglas siguientes. Inicie ambas en el estado Monitor y cámbielas a Enabled después de revisar Event Logs. Las reglas se aplican a todos los vServices protegidos por WAF.
Regla 1: Campo de session upload progress
- Pattern (Regex):
PHP_SESSION_UPLOAD_PROGRESS - Inspection Scopes: Form y Raw
- Score: Very High
Detecta el campo de formulario que activa la vía de session upload progress de CVE-2026-109619. En las aplicaciones que utilizan legítimamente esta función, excluya solo las rutas de carga que la necesiten.
Regla 2: Campo de formulario PHPSESSID
- Pattern (Regex):
^PHPSESSID$ - Inspection Scopes: Form
- Score: Very High
Detecta las solicitudes que transportan el ID de sesión en un campo de formulario llamado PHPSESSID en lugar de en una cookie; algunas vías de ataque usan esta forma, y es poco habitual en el tráfico legítimo. Si su aplicación usa un nombre de sesión distinto (session.name), utilice ese nombre.
Para que las reglas funcionen: Las reglas se analizan con las inspecciones Form y RAW del tipo de página que coincide con la solicitud. En un tipo de página sin inspección Form, los cuerpos de formularios y de cargas de archivos no se analizan.
- Mantenga OWASP check activado en la regla Any Paths y en los tipos de página que tienen su propia inspección Form o RAW.
- Añada a cada tipo de página glob su propia inspección Form y RAW con los botones Add common rule for Form y Add common rule for Raw; no confíe en los ajustes heredados.
1.3 Bloquee los cuerpos grandes y los que no se pueden inspeccionar
En la pantalla WAF Rules, realice dos ajustes en la inspección RAW:
- Establezca Raw Body Size en el cuerpo más grande que necesite la ruta (en bytes; por ejemplo, 8388608 = 8 MB en rutas sin cargas, 33554432 = 32 MB en rutas de carga). El rango predeterminado permite cuerpos de hasta 256 MB.
- Cambie el conmutador de cuerpos no analizados de Allow unparsed body a Block unparsed body. De lo contrario, un cuerpo que no cabe en el búfer de inspección se reenvía al Backend Service sin ninguna inspección de contenido.
¿Dónde? El WAF inspecciona una solicitud únicamente con los ajustes del tipo de página que coincide con su ruta. Realice estos dos ajustes en la regla Any Paths, en cada tipo de página que muestre Raw en la columna Check Fields y en cada tipo de página glob; si un tipo de página glob no tiene inspección RAW, añádala primero con Add common rule for Raw.
Precaución: Raw Body Size se aplica mientras Structure Checks está activado, en la pantalla Checks. Pruebe primero las cargas grandes legítimas. Los cuerpos enviados sin una longitud declarada no se miden con este límite; en las rutas distintas de las rutas de carga, pueden bloquearse con 2.1.
Paso 2: Medidas adicionales
Estas medidas complementan la protección esencial; elija las que se adapten a su aplicación.
2.1 Bloquee las cargas de archivos donde no las necesite
Las solicitudes de ataque son, en su mayoría, solicitudes multipart/form-data (carga de archivos). Si solo unas pocas rutas de su aplicación aceptan archivos, bloquee las solicitudes multipart a todas las demás rutas con una regla del balanceador de carga. La regla consta de dos condiciones y una acción Block. A todas las pantallas se accede desde el Configuration Menu, que se abre con el logotipo de TR7 situado en la esquina inferior izquierda.
A. Cree las condiciones (Load Balancer → Conditions → Add)
- Condición de solicitud multipart: Criteria = HTTP header, método de coincidencia Includes, Header Name = Request →
Content-Type, Query =multipart/form-data, Case Insensitive activado. Introduzca un Condition Name comomultipart-requesty guarde con Add. - Condición de rutas de carga: Criteria = Path, método de coincidencia Regex, y en Query introduzca las rutas que aceptan archivos (por ejemplo,
^/(upload|media/upload)). Introduzca un Condition Name comoupload-pathsy guarde con Add.
B. Cree la acción Block (Load Balancer → Actions → Add)
- Introduzca un Action Name (por ejemplo,
block-multipart), Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 403. - En Conditions, seleccione
multipart-requesty!upload-pathsen el mismo grupo de condiciones (and de forma predeterminada). Cada condición aparece dos veces en la lista: la propia condición y su negación (NOT), que empieza por!;!upload-pathssignifica "no es una de las rutas de carga". - Active Hit Counter para contar las solicitudes bloqueadas y guarde con Add.
C. Añada la acción al vService
- En Load Balancer → Load Balancer vService List, seleccione el vService y haga clic en Edit, seleccione la acción en Actions, dentro de Details, y haga clic en Save.
D. Bloquee también los cuerpos enviados sin una longitud declarada
- Cree otra condición HTTP header: método de coincidencia Is present, Header Name = Request →
Content-Length, Condition Name, por ejemplo,has-length. - Cree una segunda acción Block (On Request, Standard, 403). En Conditions, seleccione la condición predefinida If HTTP method is POST,
!has-lengthy!upload-pathsen el mismo grupo de condiciones, y añada la acción al campo Actions del vService. La condición POST es obligatoria; sin ella, también se bloquean las solicitudes GET sin cuerpo.
El límite de tamaño de 1.3 no ve el tamaño real de un cuerpo enviado sin una longitud declarada. Esta regla cubre tanto las cargas HTTP/1.1 transmitidas por fragmentos (chunked) como los cuerpos HTTP/2 sin longitud declarada en las rutas distintas de las rutas de carga. Las solicitudes POST sin cuerpo y sin cabecera Content-Length también coinciden con esta regla; pruébela primero en un vService que no sea de producción.
Verificación: Una solicitud multipart (curl -s -o /dev/null -w '%{http_code}\n' -F 'a=b' https://www.example.com/), una solicitud chunked HTTP/1.1 (curl -s -o /dev/null -w '%{http_code}\n' --http1.1 -H 'Transfer-Encoding: chunked' -d 'a=b' https://www.example.com/) y una solicitud HTTP/2 sin longitud declarada (printf 'a=b' | curl -s -o /dev/null -w '%{http_code}\n' --http2 -X POST -T - https://www.example.com/) a una ruta distinta de las rutas de carga deberían recibir 403, y las solicitudes a sus rutas de carga deberían pasar. --http1.1 es obligatorio para la prueba de HTTP/1.1: curl usa HTTP/2 sobre https de forma predeterminada y no envía Transfer-Encoding sobre HTTP/2. El contador aparece en la pestaña Action Hits del panel del vService.
Precaución: Una acción Block sin ninguna condición seleccionada se aplica a todas las solicitudes al vService. Enumere todas las rutas de carga de forma completa y pruebe la regla primero en un vService que no sea de producción.
2.2 Limite las solicitudes POST por cliente
Esta regla no detiene un ataque dirigido: el exploit puede funcionar con solo unas pocas solicitudes. Sí aumenta el coste para las herramientas automatizadas que prueban muchos objetivos. La regla cuenta las solicitudes POST de cada IP de cliente y bloquea con 429 las solicitudes POST de un cliente que supere el umbral. El bloqueo se levanta por sí solo cuando el contador baja del umbral.
A. Cree la acción de contador (Load Balancer → Actions → Add)
- Introduzca un Action Name, Action Type = Advanced Traffic Inspection, Fields to Track = Client IP address, Traffic Tag = por ejemplo,
post-rate(3-20 caracteres; letras, dígitos,-,_), Tracking Period = 1 minuto. - En Conditions, seleccione la condición predefinida If HTTP method is POST y guarde con Add. Así, solo se cuentan las solicitudes POST.
B. Cree la condición de umbral (Load Balancer → Conditions → Add)
- Criteria = Tracking Condition, Tracked Table =
post-rate, Tracking Criteria = HTTP requests, y el umbral con Tracking Operator (por ejemplo,> 100). Guarde con Add.
C. Cree la acción Block (Load Balancer → Actions → Add)
- Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 429.
- En Conditions, seleccione la condición de umbral del paso 3 y If HTTP method is POST en el mismo grupo de condiciones (and de forma predeterminada). Sin la condición POST, también se bloquean las solicitudes GET de un cliente que supere el umbral. Guarde con Add.
D. Añada las acciones al vService
- En el formulario Edit del vService, en Details → Actions, seleccione la acción de contador en primer lugar y la acción Block en segundo lugar, y haga clic en Save. Las acciones se ejecutan en el orden de la lista.
Verificación: En la pestaña Logs & Tracking del vService, seleccione la tabla de seguimiento de la acción de contador en la lista Logs Type; se muestran los contadores de POST por cliente. Establezca el umbral a partir del tráfico normal de su aplicación: observe en la tabla los POST por minuto de los clientes legítimos (por ejemplo, sistemas que usan una API u organizaciones detrás de una IP de salida compartida) y fije el umbral por encima de ellos.
2.3 Ponga la protección DDoS L7 en Active
Si la protección Bot/DDoS está incluida en su licencia, Source IP Request Protection, dentro de L7 DDoS Protection, limita el número total de solicitudes que una única dirección de origen puede realizar en un periodo. A diferencia de 2.2, cuenta todas las solicitudes y no necesita ninguna regla adicional.
- En el formulario Edit del vService, seleccione L7 DDoS & Threat Protection en Details y haga clic en Save (si no está activado). Cuando se activa la protección, L7 DDoS Protection se inicia en modo Monitor; en este modo, las infracciones de los límites solo se registran como eventos.
- En Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management, haga clic en el enlace Edit de la tarjeta L7 DDoS Protection.
- Establezca DDoS Protection = Active y guarde con el botón Edit.
- En la tarjeta, haga clic en el icono de lápiz del bloque Source IP Request Protection. Ajuste Time Window (valor predeterminado 10 seconds), Request Limit (valor predeterminado 1000) y Limit Action (valor predeterminado Show Captcha; también puede seleccionarse Block) según el tráfico de su aplicación y guarde con el botón Edit.
Precaución: Observe los eventos en modo Monitor durante un tiempo antes de cambiar a Active. Repita la misma observación cuando reduzca el Request Limit.
Compruebe si ha sido objetivo de un ataque
Consulte Detección y Monitorización. Se notificaron intentos de explotación antes de la divulgación pública, por lo que debe revisar los registros desde el 17 de octubre de 2026 en adelante.
Lo que un WAF Puede y No Puede Hacer
| Un WAF puede | Un WAF no puede |
|---|---|
| Bloquear formas de solicitud conocidas, como el campo de session upload progress | Corregir el código vulnerable dentro de PHP |
| Limitar el tamaño del cuerpo, las rutas de carga y las tasas de solicitudes | Medir el uso de memoria dentro del proceso de PHP |
| Bloquear las cargas en rutas que no las necesitan | Ver las solicitudes que llegan a su servidor sin pasar por él |
| Registrar las solicitudes bloqueadas y las limitadas por tasa | Deshacer código que ya se ha ejecutado en el servidor |
Las reglas WAF ganan tiempo para la actualización; la corrección duradera es actualizar PHP. Para que estas protecciones funcionen, todo el tráfico hacia sus aplicaciones PHP debe pasar por TR7 WAF-WAAP.
Detección y Monitorización
En TR7
- En la pantalla Event Logs de cada vService protegido por WAF, filtre los registros por sus reglas personalizadas y observe el campo coincidente y la puntuación.
- En la misma pantalla, revise las solicitudes bloqueadas por las reglas de tamaño del cuerpo y de cuerpos no analizados.
- Si aplicó las medidas adicionales, supervise los contadores de las reglas del balanceador de carga en la pestaña Action Hits del panel del vService, y los clientes que alcanzan el límite de tasa de POST en la tabla de seguimiento de la pestaña Logs & Tracking.
En sus servidores
- Busque en los registros de errores de PHP errores como
Allowed memory size ... exhausted, caídas de workers y respuestas HTTP 500 repetidas; preste atención a los que aparecen justo después de solicitudesmultipart/form-datagrandes. - Compruebe si las respuestas contienen cookies
PHPSESSIDinusualmente grandes o malformadas. - Compruebe si hay archivos nuevos o modificados en las raíces web y busque procesos inesperados iniciados por el usuario del servidor web, nuevas tareas cron y conexiones salientes inesperadas.
Preguntas Frecuentes
No. Los appliances de TR7 no tienen ningún componente PHP que procese solicitudes HTTP, por lo que los productos de TR7 no están afectados por estas vulnerabilidades. Consulte la sección ¿Está TR7 Afectado?
Ningún WAF puede proteger por completo frente a estas vulnerabilidades. TR7 WAF-WAAP reduce la superficie de ataque y bloquea las vías de ataque conocidas; actualizar PHP es la única corrección completa.
Utilice las dos reglas personalizadas de TR7 WAF-WAAP 1.2 contra PHP2Shell; se aplican de inmediato a todos los vServices protegidos por WAF.
No. Las vulnerabilidades están en el entorno de ejecución de PHP. Actualice el propio PHP o pida a su proveedor de hosting que lo haga.
Pueden. Los límites de tamaño del cuerpo, el bloqueo de cargas y las reglas personalizadas pueden afectar a cargas y formularios legítimos. Para las reglas WAF, comience en Monitor mode, revise Event Logs y después cambie a Blocking mode. Pruebe primero las reglas del balanceador de carga (2.1, 2.2) en un vService que no sea de producción.
Historial de Actualizaciones
- 23 de octubre de 2026 Publicación inicial.
Referencias
- Comunicado del PHP Security Team: php.net/archive/2026.php
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618): github.com/php/php-src
- GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): github.com/php/php-src
- CVE-2026-109618: cve.org
- CVE-2026-109619: cve.org
- CISA Known Exploited Vulnerabilities Catalog: cisa.gov
- Documentación de TR7: docs.tr7.com
¿Necesita ayuda para aplicar estos ajustes?
El equipo de soporte de TR7 puede revisar su configuración de WAF y ayudarle a implementar estas protecciones. Póngase en contacto con su representante de TR7 o con el equipo de soporte de TR7 en support@tr7.com.
Explorar TR7 WAF-WAAP Contactar con TR7 Soporte de Emergencia