Ciberseguridad

PHP2Shell: qué hacer si sus servidores PHP no se pueden parchar hoy

Dos fallas críticas en PHP ya se explotan y CrowdStrike anticipa una ola de brechas. Si no puede actualizar esta semana, así puede blindar sus servidores mientras tanto.

Equipo ISA

October 27, 2026

Actualizado

October 27, 2026

min de lectura

Servidor comprometido iluminado en rojo, aislado de los demás racks en verde, mientras un ingeniero de seguridad monitorea el tráfico bloqueado

En resumen

PHP2Shell (CVE-2026-109618 y CVE-2026-109619) son dos fallas críticas de PHP que permiten ejecutar código a distancia sin autenticación, y ya se explotan activamente. La corrección definitiva es actualizar, pero muchas empresas operan versiones sin soporte o aplicaciones que no pueden detenerse. Mientras tanto, el parcheo virtual con un WAF y la microsegmentación de los servidores vulnerables reducen el riesgo desde hoy.

El 23 de octubre, George Kurtz, director general de CrowdStrike, advirtió en CNBC que en los próximos meses veremos muchas brechas derivadas de una vulnerabilidad en PHP, el lenguaje detrás de cerca del 70% de los sitios web. No es una predicción lejana: los ataques empezaron antes de que existiera el parche.

Si su empresa tiene portales, intranets, tiendas en línea o sistemas internos hechos en PHP, este artículo es para usted. Y si alguno de esos sistemas no se puede actualizar esta semana, todavía más.

Cronología de PHP2Shell: del primer ataque el 17 de octubre a su inclusión en el catálogo KEV de CISA el 26 de octubre de 2026

Qué es PHP2Shell

PHP2Shell es el nombre de dos fallas en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, ambas con severidad crítica (9.2 en CVSS v4.0). Las dos permiten a un atacante ejecutar código en el servidor a distancia, sin usuario ni contraseña, con una sola petición web.

Lo que las hace especialmente peligrosas:

No dependen de la aplicación. El problema está en PHP mismo, no en su código. En servidores con Apache mod_php, el ataque puede funcionar antes de que la aplicación llegue a ejecutarse.
Afectan casi cualquier instalación web: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed y FrankenPHP.
Ninguna configuración las corrige por completo. Hay ajustes temporales que reducen el riesgo, pero la corrección real es la versión parchada.

PHP2Shell en cifras: severidad 9.2, cerca del 70% de los sitios web en PHP, 71% de instalaciones sin soporte y 0.1% parchado en 12 horas

El verdadero problema: lo que no se puede actualizar

PHP publicó las versiones corregidas el 21 de octubre (8.5.12, 8.4.27, 8.3.36 y 8.2.35). Si su servidor está en una de esas ramas, la recomendación es clara: actualice y reinicie todos los procesos de PHP.

Pero el dato que más preocupa es otro. Según Qualys, el 71% de las instalaciones de PHP que analizó corren versiones sin soporte, de la 5.4 a la 8.1. Y en las primeras 12 horas después del aviso, apenas se había parchado alrededor del 0.1%.

En la práctica, esto se ve así en muchas empresas:

Sistema operativo fuera de soporte. Ya no recibe parches del fabricante, como CentOS 7.
Aplicación atada a una versión antigua. Actualizar el lenguaje rompe el sistema, como sucede con muchas aplicaciones en PHP 7.4.
Operación que no puede detenerse. La ventana de mantenimiento llega en semanas; el ataque, en horas.

Autodiagnóstico de versiones de PHP afectadas por PHP2Shell y qué hacer en cada caso

Para estos casos, la pregunta no es solo "¿cuándo actualizo?", sino "¿cómo me protejo mientras tanto?". Hay dos respuestas que se complementan.

Primera línea: parcheo virtual con NetScaler WAF

El parcheo virtual consiste en bloquear el ataque antes de que llegue al servidor. Un firewall de aplicaciones web (WAF) inspecciona cada petición y, cuando reconoce el patrón de un exploit conocido, lo detiene en la entrada.

Para PHP2Shell, NetScaler Web App Firewall ya cuenta con firmas específicas (998061 y 998062). Para las aplicaciones publicadas a través de NetScaler, esto significa:

Protección inmediata, sin reprogramar ni reinstalar servidores.
Cero cambios en la aplicación ni en el sistema operativo.
Visibilidad total: queda registro de cada intento de ataque bloqueado.

El siguiente paso es conectar el WAF con CrowdStrike Falcon Next-Gen SIEM. Así, el WAF no solo bloquea la petición: también avisa, y la plataforma responde contra el atacante en todos sus servicios, no solo en la aplicación atacada.

Parcheo virtual con NetScaler WAF integrado con CrowdStrike Falcon Next-Gen SIEM y Fusion SOAR

Cada acción de respuesta puede ejecutarse en automático o con aprobación de su equipo. El bloqueo en firewalls de terceros se configura como un flujo de Falcon Fusion SOAR.

Segunda línea: si no puede parcharlo, aíslelo

El WAF protege lo que se publica en web. Pero ¿qué pasa si un atacante logra entrar por otro lado, o si el servidor vulnerable ya fue comprometido?

En una red plana, un servidor sin parche es la puerta a todo lo demás: el ERP, la base de datos, el controlador de dominio e incluso los respaldos. La microsegmentación coloca a ese servidor en su propia zona y decide quién puede llegar a él y hasta dónde puede avanzar un atacante.

Red plana contra red microsegmentada y política mínima para un servidor sin parche

La política mínima para un servidor sin parche es sencilla: entrada solo a los puertos de la aplicación, administración únicamente desde un servidor de salto, salida a internet bloqueada y comunicación interna solo con lo indispensable.

Dos formas de microsegmentar

Opción 1: CrowdStrike Falcon Firewall Management. Si ya tiene CrowdStrike, puede aislar los servidores con el mismo agente Falcon, sin equipos nuevos ni cambios en la red. Es la mitigación más rápida, aunque controla puertos y orígenes sin inspeccionar el tráfico que sí permite.

Opción 2: segmentación interna con FortiGate. Crea zonas separadas para los servidores sin parche e inspecciona todo lo que entra y sale con IPS. Además, extiende el parcheo virtual a aplicaciones que no son web y protege equipos donde no se puede instalar un agente, como sistemas OT y appliances. Requiere diseñar las zonas de red.

Comparativa entre CrowdStrike Falcon Firewall Management y segmentación interna con FortiGate

Lo ideal es combinar ambas: aislar hoy con Falcon y segmentar en las siguientes semanas con FortiGate, para tener defensa tanto en el servidor como en la red.

Hoja de ruta: ganar tiempo sin perder el rumbo

El parcheo virtual y la microsegmentación no sustituyen la actualización. Lo que hacen es darle tiempo para hacerla con calma y sin poner en riesgo la operación.

Hoja de ruta para proteger servidores PHP: hoy, semanas y meses

Mientras tanto, revise también las mitigaciones temporales que publicó el proyecto PHP. La más importante para CVE-2026-109619 es desactivar session.upload_progress.enabled y reiniciar los procesos. Pruebe cualquier cambio antes de aplicarlo en producción.

¿Sabe cuántos servidores PHP tiene expuestos hoy?

En ISA le ayudamos a identificar qué aplicaciones están en riesgo, cuáles aislar primero y con qué opción protegerlas esta semana. Solicite una evaluación de sus aplicaciones expuestas o comience con el ISA Security Check, un diagnóstico sin costo de 2 horas basado en NIST CSF 2.0.

Referencias

Sin costo · 2 horas

¿Qué tan expuesta está tu empresa?

El ISA Security Check evalúa tu postura de ciberseguridad con NIST CSF 2.0 e ISO/IEC 27001. Sin agentes, sin impacto a producción. Reporte y plan priorizado en 5 días hábiles.

Agendar diagnóstico