PHP2Shell: el parche cierra la falla, la detección cierra la ventana

El 21 de octubre de 2026, el proyecto PHP corrigió la CVE-2026-109618 y la CVE-2026-109619, apodadas PHP2Shell: ejecución remota de código sin autenticación en instalaciones que atienden solicitudes web. Los detalles se filtraron antes de la fecha acordada, y Amazon informa un intento de explotación cuatro días antes de la corrección. El parche responde si la falla sigue abierta. La pregunta que no responde es otra: ¿alguien entró mientras estaba abierta?

Este artículo resume el threat brief que Network Secure publicó sobre el caso. Como es un evento en curso, separamos lo que está confirmado por fuente primaria (comunicado de PHP, advisories en GitHub, registros CVE/NVD) de lo que todavía es reporte de quien observó el hecho. El material es defensivo: no incluye payloads ni instrucciones de explotación.

Qué es PHP2Shell

PHP2Shell es el nombre informal de dos vulnerabilidades en el núcleo de PHP — en el runtime, no en la aplicación. Actualizar WordPress, Drupal o plugins no lo resuelve. Ambas explotan el manejo de condiciones excepcionales: cuando se agota la memoria u ocurre un error fatal, PHP abandona la operación sin la limpieza normal, y estructuras internas quedan parcialmente inicializadas o apuntando a memoria ya liberada.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — RCE por corrupción por falta de memoria. Una falla de asignación interrumpe PHP mientras datos internos de la solicitud aún no fueron inicializados, y la limpieza trata ese estado inválido como válido. Con Apache mod_php, el ataque se ejecuta antes de cualquier código de la aplicación.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — RCE por estado global obsoleto. Un estado de una solicitud sobrevive después de que la memoria es liberada y lo usa la solicitud siguiente en el mismo worker (use-after-free). Los casos validados incluyen el progreso de carga de sesión, activo por defecto, en mod_php y PHP-FPM. También hay divulgación de memoria: datos que pasaron por el proceso pueden quedar expuestos incluso sin ejecución de código.

PHP asignó a cada una un CVSS v4.0 de 9,2 — complejidad alta, pero sin exigir autenticación ni interacción del usuario. Para entender cómo leer esa nota, vea nuestra guía de CVSS.

Qué está confirmado y qué sigue siendo reporte

Al 23/10, las dos CVEs no estaban en el catálogo KEV de CISA, y el EPSS era de 11,6% y 6,0%. Estos indicadores cambian rápido; conviene volver a consultarlos. Si el tema es priorización, vea cómo priorizar vulnerabilidades con CVSS, EPSS y KEV.

Quién está expuesto

PHP considera en riesgo toda instalación que atiende solicitudes web. El modo de ejecución cambia la urgencia:

• Apache con mod_php — prioridad máxima. RCE validada vía HTTP en las dos CVEs, antes de cualquier código de la aplicación.
• PHP-FPM — alta. CVE-2026-109619 validada en el ciclo de sesión; CVE-2026-109618 susceptible por análisis de código, sin exploit completo demostrado.
• FrankenPHP, LiteSpeed y php-cgi — tratar como expuestos. Están en la lista de PHP, pero no hay validación pública por modo.

Nuevo el 23/10: CVE-2026-115560. PHP publicó un aviso informativo sobre otra falla en el progreso de carga de sesión que afecta incluso a versiones ya corregidas, pero solo bajo una combinación poco común de configuración y código. PHP no la clasifica como parte de PHP2Shell. La mitigación es la misma ya indicada para la CVE-2026-109619: session.upload_progress.enabled=0.

Tres trampas de inventario aparecen con frecuencia:

• php -v engaña. El binario de línea de comandos puede ser distinto del que corre en FPM o en Apache.
• Los workers en memoria mantienen el código vulnerable hasta el reinicio, aunque el paquete nuevo esté instalado.
• PHP de terceros. El NVD ya asocia appliances de otros fabricantes a las CVEs; hostings y paneles también cuentan.

Cuatro días antes del parche

Entre el 17 y el 21 de octubre no había CVE, parche ni firma. En ese intervalo, solo la detección por comportamiento y la inteligencia de amenazas podían ver el ataque. La propia Amazon recomienda investigar desde el 17/10.

Por qué el parche no cierra la ventana por sí solo

La ventana de exposición empieza cuando alguien que no es el defensor puede explotar la falla y termina cuando la organización comprueba dos cosas: que el activo dejó de ser explotable y que nadie lo explotó en el intervalo. La gestión de vulnerabilidades se ocupa del primer cierre; la detección y respuesta, del segundo.

• Un log sin errores no prueba seguridad. El propio PHP advierte que la falla puede ocurrir antes de que se escriba el mensaje.
• “Corregido” puede ser provisorio. Los workers antiguos siguen en memoria hasta el reinicio, y la CVE-2026-115560 afecta a versiones ya corregidas.
• Son dos relojes. El tiempo de corrección mide cuánto tiempo la falla estuvo abierta. El MTTD y el MTTR del SOC miden cuánto tiempo un intruso estaría en el entorno sin ser notado y cuánto tardaría en ser contenido. Uno no reemplaza al otro.
• La inteligencia externa no es evidencia interna. Los intentos en honeypots prueban que la falla es atacada en el mundo, no que su servidor lo fue — ni que no lo fue.

Dónde deja rastros el ataque

La explotación en sí puede no generar log. Lo que el atacante hace después casi siempre lo genera. En términos conceptuales, la cadena es:

1. Solicitud a PHP
2. Falta de memoria o error fatal
3. Estado inconsistente en el worker
4. Ejecución de código en el servidor

El código se ejecuta con los privilegios de la cuenta del worker web. Eso no es acceso administrativo por sí solo, pero esa cuenta suele leer archivos de configuración, credenciales de base de datos y claves de integración, y alcanzar servicios internos. La señal más fuerte para el SOC está en la post-explotación.

Qué buscar desde el 17 de octubre

Sin IoCs publicados, la búsqueda parte de hipótesis sobre comportamiento. Las seis siguientes fueron escritas para servidores Linux que ejecutan PHP; registre lo que no pudo verificarse por falta de telemetría.

1. Worker web iniciando procesos. apache2, httpd, php-fpm o lsphp lanzando shells, intérpretes o utilidades de descarga (ATT&CK T1059.004, T1505.003). Fuente: EDR, auditd o Sysmon for Linux.
2. Archivos nuevos donde escribe el servidor web. Scripts o binarios creados después del 17/10 en directorios web, uploads, caché o /tmp (T1505.003, T1105). Fuente: FIM, EDR, comparación con el repositorio.
3. Salida de red inédita. Conexiones iniciadas por el usuario del servidor web hacia destinos sin historial (T1071, T1105). Fuente: firewall, NDR, proxy de salida, flow logs.
4. Errores fatales concentrados. “Memory exhausted”, timeouts y workers reiniciándose, agrupados por ruta, tipo de contenido u origen (T1190). Fuente: logs de PHP, PHP-FPM, servidor web y WAF.
5. Credenciales del servidor usadas en otro lugar. Lectura de .env y archivos de configuración seguida de inicios de sesión de cuentas de servicio desde orígenes nuevos (T1552.001, T1078).
6. Consumo anómalo de CPU por procesos ligados al servidor web, sin aumento correspondiente de tráfico (T1496).

Si hay indicios, trátelo como incidente, no como parche. Preserve memoria, discos y logs del período antes de corregir: reiniciar o actualizar antes de la recolección borra exactamente lo que la investigación necesita. Dada la divulgación de memoria confirmada, evalúe rotar credenciales, tokens y claves usados por los servidores expuestos. Si necesita apoyo, vea Respuesta a Incidentes.

Recomendaciones técnicas

Corregir es la única solución completa; lo demás compra tiempo. Ante dudas sobre un parámetro, prevalece el advisory oficial de PHP.

1. Inventariar todo PHP — ramas paralelas, contenedores, paneles de hosting y appliances — con versión, modo de ejecución, exposición y responsable.
2. Actualizar a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido del proveedor; en las ramas 7.4 a 8.1, backport o migración. Reconstruir imágenes de contenedor.
3. Reiniciar todos los procesos que cargan PHP y confirmar que los workers en ejecución usan el build corregido — no el php -v.
4. Desactivar el progreso de carga de sesión con session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la configuración del servidor (no vía ini_set()), y mantenerlo incluso después de actualizar, hasta la release que corrija la CVE-2026-115560.
5. En PHP 8.5, fatal_error_backtraces=0 de forma administrativa, lo que elimina el productor del caso confirmado de RCE.
6. Limitar solicitudes: post_max_size conservador, límites de multipart en el frontend y bloqueo de multipart donde la aplicación no lo usa.
7. Cubrir los servidores PHP expuestos con telemetría de procesos y red (EDR o auditd, firewall o NDR), no solo logs de acceso, integrada al SIEM o XDR.
8. Usar el WAF como paliativo, no como solución: Cloudflare observó intentos de eludir sus reglas, y el tráfico directo al origen evita el WAF.

Para activos que no pueden corregirse ni compensarse, CERT-EU y el Centro Canadiense de Ciberseguridad recomiendan aislarlos de las redes públicas hasta que la corrección se aplique y se verifique.

Preguntas que la dirección debe hacer

• ¿Cuántos activos expuestos a internet ejecutan PHP, y cuántos ya tienen remediación validada en el runtime?
• ¿Revisamos señales de explotación desde el 17/10? ¿Con qué cobertura de telemetría, y qué quedó sin cobertura?
• Si un servidor hubiera sido comprometido el 18/10, ¿cuándo lo habríamos sabido?
• ¿Quién puede decidir aislar un servicio a las 3 de la mañana de un sábado?
• ¿Qué riesgos se aceptaron, por quién, con qué control compensatorio y hasta cuándo?

Las primeras pruebas de concepto surgieron hacia las 2 h UTC de un martes. Montar esa cobertura internamente exige turnos, SIEM, SOAR, inteligencia de amenazas y un equipo difícil de contratar y retener. Muchas empresas combinan los dos modelos: el equipo interno mantiene el contexto y las decisiones de negocio, y el SOC como servicio garantiza la vigilancia continua y la primera respuesta. La comparación está en SIEM, MDR o SOC as a Service.

Cómo actúan el SOC y el MDR de Network Secure en un caso así

Una falla sin IoC genera señales débiles y dispersas: un error fatal aquí, un proceso hijo allá, una conexión nueva en otro lado. Aisladas, ninguna justifica una alarma; correlacionadas en el mismo host y en la misma ventana de tiempo, cuentan una historia. En el SOC 24×7 y MDR de Network Secure, la plataforma Open-XDR recolecta telemetría de endpoint, red, nube, identidad y firewalls; la IA hace la clasificación y la correlación; el analista valida lo crítico, mapea el ataque en MITRE ATT&CK, conduce la contención y entrega una notificación que su equipo puede ejecutar. El SOC está certificado ISO/IEC 27001:2022, con auditoría de Bureau Veritas.

Para dejar claro el límite: no afirmamos haber detectado explotación de PHP2Shell en clientes, ni que algún servicio identifique la falla automáticamente. Aplicar parches y reiniciar servicios sigue siendo responsabilidad de quien opera cada activo, salvo contrato específico.

Preguntas frecuentes

¿Qué es PHP2Shell?

Es el nombre informal de dos vulnerabilidades críticas en el núcleo de PHP, la CVE-2026-109618 y la CVE-2026-109619, corregidas el 21/10/2026. Permiten ejecución remota de código sin autenticación en instalaciones que atienden solicitudes web.

¿Qué versiones de PHP corrigen PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las ramas 8.1, 8.0 y 7.4 no tienen release oficial, solo backports mínimos en código fuente o paquetes de proveedores LTS; de la 7.3 hacia atrás no hay corrección.

¿Actualizar WordPress o los plugins lo resuelve?

No. La falla está en el runtime de PHP, no en la aplicación. Es necesario actualizar PHP y reiniciar todos los procesos que lo cargan.

Si ya apliqué el parche, ¿debo hacer algo más?

Sí. Confirme que los workers en ejecución usan el build corregido, mantenga session.upload_progress.enabled=0 hasta la corrección de la CVE-2026-115560 e investigue señales de explotación desde el 17/10/2026, cuando surgieron los primeros intentos reportados.

¿Existen indicadores de compromiso (IoCs) de PHP2Shell?

Al 23/10/2026, ninguna fuente primaria había publicado IoCs, actores ni campañas asociados. La detección depende del comportamiento: procesos iniciados por el worker web, archivos nuevos en directorios web y conexiones de salida inéditas.

Fuentes consultadas hasta el 23 de octubre de 2026: comunicados de seguridad de PHP del 21/10 y 23/10; advisories GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp; registros del NVD; catálogo KEV de CISA (versión 2026.10.23); EPSS de FIRST; CERT-EU, advisory 2026-018; Canadian Centre for Cyber Security, AL26-026; publicaciones de Wiz Research, Amazon Threat Intelligence, Cloudflare, Qualys, watchTowr y Field Effect. El estado en KEV, el EPSS y los indicadores cambian con frecuencia. Las hipótesis de búsqueda son derivación técnica de Network Secure, no indicadores publicados.

Referencias oficiales

• Security advisory: critical remote code execution vulnerabilities (21/10/2026) — The PHP Group
• Informational advisory: session upload progress, CVE-2026-115560 (23/10/2026) — The PHP Group
• GHSA-w8hw-w9fx-j79w — RCE via OOM corruption (CVE-2026-109618) — PHP/GitHub
• GHSA-6wmf-4rv5-p3rp — RCE via stale global state (CVE-2026-109619) — PHP/GitHub
• CVE-2026-109618 Detail — NIST NVD
• CVE-2026-109619 Detail — NIST NVD
• CISA — Known Exploited Vulnerabilities Catalog
• Security Advisory 2026-018 — Critical Vulnerabilities in PHP — CERT-EU
• PHP2Shell: AI uncovers critical RCE vulnerabilities — Wiz Research
• PHP2Shell exploitation prior to public disclosure in MadPot — Amazon Threat Intelligence
• Cloudflare deploys protections against php2shell — Cloudflare