PHP2Shell: Qué significa para sus sitios web y cómo le ayuda Nexusguard

Es posible que haya visto noticias esta semana sobre un par de graves fallos de seguridad en PHP, el software que hace funcionar una gran parte de los sitios web en todo el mundo, incluidos WordPress, tiendas en línea y muchas aplicaciones empresariales personalizadas.

‍

El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones de emergencia para dos problemas conocidos conjuntamente como PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Ambos están clasificados como críticos. En términos sencillos: alguien en internet, sin necesidad de nombre de usuario ni contraseña, podría ejecutar su propio código en un servidor web vulnerable. Es tan grave como suena. Esto no significa que todos los sitios web basados en PHP estén ya comprometidos, ni que el WAF de protección de aplicaciones de Nexusguard esté en riesgo.

‍

A continuación, explicamos en qué consiste el problema, si usted está afectado, qué estamos haciendo nosotros y qué debe hacer usted.

‍

En qué consiste

Piense en PHP como el motor que impulsa muchos sitios web. Cuando un visitante carga una página, rellena un formulario o sube un archivo, PHP suele ser el software que recibe esa solicitud y la convierte en una respuesta.

‍

PHP2Shell no es un error de un plugin o de una marca específica de creador de sitios web. Está en el propio PHP, en la forma en que el motor gestiona las solicitudes web entrantes, especialmente el tipo de solicitud que utilizan los navegadores para subir archivos. El problema puede aparecer antes de que se ejecute el código de su propio sitio web. Actualizar un tema o un plugin no es suficiente. Es necesario actualizar el software PHP del servidor.

‍

Existen dos fallos relacionados:

‍

Cuando PHP se queda sin memoria. Si PHP supera su límite de memoria al procesar una solicitud, puede fallar de forma insegura. En lugar de detenerse simplemente, puede dejar el servidor en un estado que un atacante puede aprovechar. Los avisos públicos confirman que esto puede llevar a una toma de control total del servidor web.

‍

Cuando se reutilizan datos residuales. Los servidores web suelen reutilizar el mismo proceso PHP para muchos visitantes, uno tras otro. Si una solicitud deja ese proceso en un estado desordenado, la siguiente solicitud en el mismo proceso puede ser gestionada incorrectamente. Los investigadores han demostrado que esto también puede conducir a una toma de control. Un desencadenante confirmado implica una función integrada de PHP que rastrea el progreso de la carga de archivos. Esa función está activada por defecto, incluso si su aplicación nunca la solicitó.

‍

Los informes públicos han descrito que los atacantes han utilizado estos problemas antes desde que se anunciaron. Esa es una razón para tratar la actualización como urgente. No es una prueba de que su sitio web en particular haya sido atacado.

‍

¿Está usted afectado?

Puede estar afectado si alguno de sus sitios web públicos, API o portales de clientes utiliza PHP y aún no ha recibido la actualización de emergencia del 21 de octubre.

‍

Va por buen camino si:

• sus sitios no utilizan PHP en absoluto, o
• su proveedor de alojamiento, equipo de TI o socio de servicios gestionados ya ha aplicado las versiones de PHP parcheadas (8.5.12, 8.4.27, 8.3.36 o 8.2.35) y reiniciado PHP, o ha aplicado la actualización de seguridad del proveedor de su sistema operativo.

‍

PHP 7.4 a 8.1 solo reciben backports mínimos a nivel de código fuente. PHP 7.3 y versiones anteriores no recibirán correcciones. Si utiliza una de esas versiones, necesita un plan para migrar a una rama de PHP con soporte; un pequeño parche no es suficiente.

‍

Si no está seguro, es algo habitual. Muchas organizaciones ejecutan PHP sin pensarlo; simplemente es "el sitio web". Pregunte a quien se encargue de su alojamiento, WordPress o servidores de aplicaciones.

‍

¿Está afectado Nexusguard?

El WAF de protección de aplicaciones de Nexusguard no se ve afectado. Nuestro WAF no es PHP. No ejecuta el código PHP de su sitio web, y estas vulnerabilidades no son un defecto de la plataforma Nexusguard.

‍

Si ejecuta PHP en sus propios servidores (o en los servidores de su proveedor de alojamiento) detrás de Nexusguard, esos servidores aún pueden estar en riesgo hasta que se actualice PHP. Se trata de un problema de software de origen, el mismo tipo de problema de "por favor, parche la aplicación" que vemos con otro software web ampliamente utilizado. Actualizar PHP es la medida principal.

‍

Esto tampoco es una inundación DDoS. La protección DDoS de Nexusguard no es la vía que utiliza un atacante para PHP2Shell. El riesgo afecta al tiempo de ejecución de la aplicación en el servidor web, no a la capacidad de la red.

‍

Cómo estamos ayudando

Sabemos que parchear un conjunto de sitios web lleva tiempo: hay que encontrar dónde se ejecuta PHP, planificar una ventana de mantenimiento y realizar pruebas. Mientras lo hace, no debería estar desprotegido.

‍

Estamos implementando reglas de WAF en toda la plataforma de protección de aplicaciones de Nexusguard para detectar intentos de explotación dirigidos a CVE-2026-109618 y CVE-2026-109619. Estas reglas le brindan una capa adicional de visibilidad y protección mientras aplica los parches.

‍

Considérelas como un cinturón de seguridad, no como la reparación. No sustituyen la actualización de PHP. Parchear sus servidores sigue siendo la única solución completa. Algunas de las rutas de PHP2Shell residen dentro del propio servidor y no pueden cerrarse por completo mediante un firewall de aplicaciones web, por muy bien configurado que esté.

‍

La protección a nivel de red solo ayuda con el tráfico que realmente pasa a través de ella. Si sus servidores de origen siguen aceptando tráfico web directamente desde Internet, un atacante puede evitar Nexusguard. Asegúrese de que esos servidores solo acepten tráfico web proveniente de su servicio de protección.

‍

Si tiene preguntas sobre su exposición o necesita ayuda para revisar tráfico sospechoso, póngase en contacto con nuestro equipo de soporte. Estamos aquí para acompañarle en este proceso; no necesita ser un ingeniero de seguridad para consultarnos.

‍

Qué debe hacer

Aunque no sea usted quien inicia sesión en el servidor, entregue esta lista a su equipo de TI, proveedor de hosting o socio tecnológico. Incluya WordPress, Magento y cualquier aplicación web personalizada accesible desde internet.

‍

1. Actualice PHP de inmediato. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si utiliza los paquetes de PHP de su proveedor de sistema operativo, aplique la actualización de seguridad de dicho proveedor. No espere a una semana más tranquila si los sitios son públicos.

2. Reinicie todos los procesos de PHP tras la actualización. Esto incluye los pools de PHP-FPM, Apache y cualquier proceso de PHP de larga ejecución. Instalar el paquete no es suficiente. La corrección no surte efecto hasta que los procesos antiguos se hayan cerrado.

3. Planifique una actualización si utiliza una versión de PHP que ha llegado al fin de su vida útil. PHP 7.4 a 8.1 solo reciben backports mínimos a nivel de código fuente, y PHP 7.3 y versiones anteriores no recibirán correcciones. Si utiliza alguna de estas versiones, migre a una rama con soporte lo antes posible.

4. Aplique medidas de mitigación provisionales si no puede parchear de inmediato. Estas reducen el riesgo, pero no sustituyen la aplicación de parches. Pida a su administrador que realice los cambios en la configuración del servidor principal o del pool de PHP-FPM y luego reinicie PHP. Los ajustes realizados mediante ini_set() o .user.ini no protegen contra estas vulnerabilidades.

• Establezca session.upload_progress.enabled = 0de Nexusguard.
• Reduzca post_max_size al valor más bajo con el que su aplicación pueda funcionar.
• Bloquee el límite de memoria para que las aplicaciones no puedan sobrescribirlo; por ejemplo,
  ‍php_admin_value[memory_limit] en la configuración del pool de PHP-FPM, o
  ‍php_admin_value memory_limit en Apache.
• En PHP 8.5, configure fatal_error_backtraces = 0de Nexusguard.

5. Revise sus registros. Busque solicitudes POST inusuales con multipart/form-data cuerpos, especialmente aquellos que contengan un campo PHP_SESSION_UPLOAD_PROGRESS junto con una cookie de sesión PHPSESSID . Busque también bloqueos o reinicios inesperados de los procesos de PHP. Recomendamos revisar la actividad desde el 17 de octubre de 2026 en adelante.

6. No deje sus servidores de origen expuestos directamente. La protección a nivel de red solo ayuda al tráfico que pasa a través de ella. Asegúrese de que sus servidores de origen acepten tráfico web únicamente desde su servicio de protección, no directamente desde internet.

7. Llámenos si necesita ayuda. Póngase en contacto con nuestro equipo de soporte si tiene preguntas sobre la exposición o para revisar tráfico inusual. No tiene por qué diagnosticar esto a solas.
   ‍

Conclusión

PHP2Shell es urgente para los sitios web que aún ejecutan versiones de PHP sin parches. No es un problema del motor WAF de Nexusguard, y estamos añadiendo detección adicional mientras los clientes actualizan. La solución definitiva sigue siendo la actualización de PHP.

‍

Estamos monitoreando la situación y revisaremos esta guía si los hechos cambian.
‍

Fuentes

• Aviso del proyecto PHP para CVE-2026-109618
• Aviso del proyecto PHP para CVE-2026-109619
• Blog de seguridad de AWS sobre mitigaciones de PHP2Shell (21 de octubre de 2026)
• Boletín de seguridad de AWS 2026-143-AWS
  ‍

Lista de verificación de publicación

• Informa, educa, indica el impacto y señala qué hacer
• Lista de verificación de avisos completada y coherente con este borrador
• Sin recetas de explotación ni cargas útiles más allá de lo que ya es público
• Sin nombres de clientes, topología no publicada, límites de responsabilidad ni tablas de créditos de SLA
• Descargo de responsabilidad de plataforma más reciente presente
• Escrito para una audiencia general de clientes, no solo para lectores técnicos
• Investigación de seguridad/amenazas: pendiente
• Producto / Legal / clasificación / Comunicaciones (Donny para esta fase de documentación): pendiente