Vulnerabilidades críticas PHP2Shell bajo explotación activa en PHP
Dos fallas de ejecución remota de código sin autenticación (CVE-2026-109618 y CVE-2026-109619) afectan toda instalación PHP que sirva peticiones web; CISA, SANS ISC y CSA Labs confirman intentos de explotación activa, incluidos despliegues de malware tipo Mirai.
- Dos vulnerabilidades críticas de PHP, bautizadas PHP2Shell (CVE-2026-109618 y CVE-2026-109619), permiten ejecución remota de código sin autenticación en toda instalación que sirva peticiones web: Apache con mod_php (el escenario de mayor riesgo según el propio proyecto PHP), PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
- CISA publicó la alerta el 21 de octubre sin evidencia de explotación; para el 23-25 de octubre, SANS ISC, CSA Labs y múltiples medios especializados ya reportan intentos de explotación activa, incluidos intentos de desplegar malware de la familia Mirai sobre hosts comprometidos. Con tres fuentes primarias (CISA, SANS ISC, CSA Labs) llegando al hecho por caminos independientes, el patrón de explotación activa está suficientemente respaldado para afirmarlo.
- No existe aún una brecha chilena confirmada vinculada a este caso, pero PHP sustenta una porción muy relevante de los sitios corporativos, de comercio electrónico y de gobierno que operan en Chile (WordPress, Drupal, Magento y aplicaciones a medida en hosting compartido o VPS). Esa es la razón de esta bajada: cualquier organización chilena con un stack PHP expuesto a Internet y sin parchear es un objetivo potencial desde ya.
Qué pasó
El 21 de octubre, CISA emitió una alerta urgente instando a parchear de inmediato CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades en PHP agrupadas bajo el apodo PHP2Shell que permiten ejecución remota de código (RCE) sin autenticación.
Según la alerta y el aviso del propio proyecto PHP, las fallas afectan toda instalación de PHP que procese peticiones web, incluyendo:
- Apache con
mod_php— el escenario que PHP considera de mayor riesgo - PHP-FPM
php-cgi- FrankenPHP
- LiteSpeed
Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. CISA actualizó la alerta el 23 de octubre para añadir una regla Sigma de detección, incorporar recursos de socios y reforzar la guía de mitigación — una señal de que, aunque la alerta original no reportaba explotación confirmada, el escenario estaba evolucionando rápido.
Y efectivamente evolucionó: entre el 23 y el 25 de octubre, SANS ISC publicó un *wrap-up* de la vulnerabilidad con infocon en amarillo, segu-info documentó evidencia real de RCE en un caso observado, y The Hacker News reportó intentos de explotación masiva con despliegue de malware Mirai, además de actividad de escaneo global que investigadores vinculan, con reservas, a Corea del Norte. CSA Labs, por su parte, publicó una nota de investigación que plantea explotación previa a la divulgación pública de la falla, describiéndola además como una vulnerabilidad hallada mediante IA.
Adicionalmente, dos días después del parche de emergencia, PHP advirtió sobre otro riesgo de RCE sin parchear, sin CVE asignado al momento de esta publicación — un dato relevante que separa de las dos CVE principales y que amerita seguimiento propio.
Por qué importa acá
No tenemos una entidad chilena identificada como víctima ni una alerta de ANCI asociada a este caso — y no la vamos a inventar.
Lo que sí es razonable afirmar, como evaluación de confianza alta, es que PHP sostiene una fracción muy significativa del parque de sitios web chilenos: WordPress, Drupal y Magento —todos basados en PHP— son las plataformas más usadas por pymes, retailers y medios en Chile, típicamente desplegadas en hosting compartido o VPS donde php-cgi o PHP-FPM quedan expuestos directamente o detrás de un proxy mínimamente configurado. No contamos con una cifra exacta de exposición local — eso lo dejamos como no sabemos hasta que haya telemetría de ANCI o de un escaneo propio.
Lo que cambia el cálculo de riesgo es la naturaleza de la falla: no requiere autenticación, afecta el modo de despliegue más común (mod_php, que el propio PHP marca como el de mayor riesgo) y ya hay evidencia —no solo teórica— de explotación con fines de reclutamiento a botnets tipo Mirai, es decir, barrido automatizado masivo más que un ataque dirigido. Ese tipo de explotación no discrimina geografía: escanea rangos de IP completos.
Si una organización chilena identifica un servidor PHP comprometido a partir de esta vulnerabilidad y ese servicio califica como esencial bajo la Ley 21.663, corresponde evaluar el deber de reporte a ANCI. No precisamos aquí plazos específicos porque no los verificamos contra el texto reglamentario vigente para este caso puntual; lo que sí corresponde hoy es registrar el hallazgo, documentar la cadena de eventos y tenerla lista si el reporte aplica.
Anatomía del ataque
Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.
T1190— Vector de entrada: una instancia PHP expuesta a Internet (Apache/mod_php, PHP-FPM, php-cgi, FrankenPHP o LiteSpeed) procesa una petición que dispara CVE-2026-109618 o CVE-2026-109619 sin requerir credenciales.T1505.003— El nombre 'PHP2Shell' describe el objetivo típico post-explotación: dejar una web shell en el docroot para acceso persistente, consistente con lo reportado por segu-info como 'evidencia real de RCE'.T1059.004— Tras el RCE, el proceso del servidor web (php-fpm, apache2, httpd) genera un intérprete de shell como proceso hijo para ejecutar comandos — la base de la regla de detección de esta pieza.T1584.005— The Hacker News reporta intentos de desplegar malware Mirai sobre hosts PHP comprometidos, es decir, reclutamiento a una botnet existente más que un objetivo de espionaje dirigido.
Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.
GV GobernarQuien decide, que se reporta y a quien
El gobierno del riesgo aquí pasa por tener un SLA de parcheo definido para vulnerabilidades críticas en software expuesto a Internet, y por saber de antemano quién decide si un hallazgo de web shell en un servicio esencial activa el deber de reporte bajo Ley 21.663. No cites plazos exactos sin haberlos verificado contra la normativa vigente para tu sector — pero sí deja designado, hoy, quién toma esa decisión.
- Definir o confirmar un SLA de parcheo de 48 horas para CVSS ≥ 9.0 en activos expuestos a Internet.
- Designar explícitamente quién evalúa el deber de reporte a ANCI si se confirma compromiso en un servicio esencial.
ID IdentificarSi esto me toca, por donde me toca
Antes de parchear hay que saber dónde está PHP. En la práctica esto significa inventariar no solo los servidores que uno administra directamente, sino también CMS y plugins de terceros (WordPress, Drupal, Magento) y aplicaciones a medida corriendo sobre LAMP/LEMP, incluyendo instancias en hosting compartido que IT puede no tener mapeadas formalmente.
- Levantar inventario de toda instancia PHP expuesta a Internet, indicando versión exacta y modo de despliegue (mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed).
- Revisar específicamente los despliegues con Apache + mod_php: es el escenario que el propio proyecto PHP marca como de mayor riesgo.
- Catalogar CMS de terceros (WordPress, Drupal, Magento) y sus dependencias PHP, incluyendo los alojados por proveedores externos.
PR ProtegerComo evito que ocurra
La mitigación real es el parche. Mientras se completa el rollout, la exposición se reduce sacando PHP-FPM y php-cgi de la vista directa de Internet y limitando lo que el proceso del servidor web puede hacer si igual lo explotan.
Controles priorizados
P1: esta semana · P2: este mes · P3: este trimestre
| Prio | Control | Esfuerzo | Mapeo |
|---|---|---|---|
| P1 | Actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35 según la rama en uso, priorizando servidores con Apache + mod_php. | medio | MITRE ATT&CK M1051 CIS Controls v8 7.1 ISO 27001 A.8.8 |
| P1 | Eliminar la exposición directa a Internet de PHP-FPM y php-cgi, dejándolos siempre detrás de un reverse proxy. | medio | MITRE ATT&CK M1030 CIS Controls v8 12.2 ISO 27001 A.8.20 |
| P2 | Ejecutar el proceso del servidor web con usuario sin privilegios de escritura sobre el docroot. | bajo | MITRE ATT&CK M1022 CIS Controls v8 3.3 ISO 27001 A.8.3 |
| P2 | Desplegar o validar sensor EDR/Sysmon-Linux en hosts con servidores PHP para capturar telemetría de creación de procesos. | medio | MITRE ATT&CK M1040 CIS Controls v8 8.2 ISO 27001 A.8.16 |
| P3 | Revisar y actualizar reglas de WAF del proveedor para tráfico anómalo hacia endpoints PHP-FPM/FastCGI. | bajo | MITRE ATT&CK M1021 CIS Controls v8 13.3 ISO 27001 A.8.23 |
El parche es la mitigación real; todo lo demás reduce exposición mientras se despliega. Prioriza los hosts con Apache + mod_php: es el escenario que el propio proyecto PHP marca como de mayor riesgo, y el más común en hosting compartido económico, donde suele vivir el PHP chileno de pymes.
DE DetectarComo me doy cuenta de que ya ocurrio
Sin un IOC público confirmado (hash, IP, dominio), la detección útil hoy es conductual: un servidor web que de pronto genera un intérprete de shell como proceso hijo es la señal post-explotación más confiable para esta familia de vulnerabilidades, independiente del vector de entrada exacto.
- Desplegar la regla Sigma de esta pieza (o su traducción) en modo *experimental* y revisar resultados durante una semana antes de subir el nivel de alerta.
- Correlacionar cualquier disparo con el inventario de PHP levantado en ID: priorizar triage en hosts con versión sin parchear.
Qué necesitas tener logueado
- Telemetría de creación de procesos en Linux (Sysmon for Linux, auditd, o EDR equivalente) en hosts con servidor PHP
- Logs de acceso y error del servidor web (Apache, nginx, LiteSpeed)
- Logs de WAF/reverse proxy frente a las instancias PHP
- Logs de firewall/proxy saliente para detectar conexiones post-compromiso hacia infraestructura de botnet
Reglas y consultas de detección
title: Posible explotación de PHP2Shell vía shell hijo de proceso web
id: e3f9a2c1-7b5d-4a18-9f3e-2d6c8a1b4f70
status: experimental
description: Detecta la generación de un intérprete de comandos como proceso hijo de procesos típicos de servidores PHP (php-fpm, apache2, httpd, nginx, litespeed, frankenphp, php-cgi). Patrón consistente con explotación post-RCE de CVE-2026-109618 / CVE-2026-109619 u otro webshell equivalente.
references:
- https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/php-fpm'
- '/apache2'
- '/httpd'
- '/nginx'
- '/litespeed'
- '/frankenphp'
- '/php-cgi'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/python3'
- '/perl'
- '/curl'
- '/wget'
condition: selection_parent and selection_child
falsepositives:
- Scripts legítimos que invocan shell_exec/exec/system de PHP para tareas administrativas (backups, conversión de imágenes)
- Plugins de CMS que ejecutan utilidades del sistema de forma legítima
level: high
DeviceProcessEvents
| where InitiatingProcessFileName has_any ("php-fpm", "apache2", "httpd", "nginx", "litespeed", "frankenphp", "php-cgi")
| where FileName has_any ("sh", "bash", "dash", "python3", "perl", "curl", "wget")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName
<rule id="100620" level="12">
<if_group>audit_command</if_group>
<field name="audit.exe">php-fpm|apache2|httpd|nginx|litespeed|frankenphp|php-cgi</field>
<field name="audit.execve.a0">^sh$|^bash$|^dash$|^python3$|^curl$|^wget$</field>
<description>Posible explotación PHP2Shell: shell generado desde proceso de servidor web (CVE-2026-109618 / CVE-2026-109619)</description>
<mitre>
<id>T1190</id>
</mitre>
</rule>
Esta detección se basa en un patrón de comportamiento, no en un payload específico, así que generará ruido en entornos donde scripts PHP legítimos invocan shell_exec, exec o system para tareas administrativas (backups automatizados, conversión de imágenes, utilidades de mantenimiento embebidas en cron). Antes de subir el nivel de alerta, levanta una lista blanca de esos scripts conocidos y sus rutas, y corre la regla en modo silencioso (solo log) durante al menos una semana.
RS ResponderContencion y erradicacion
Si la regla dispara o se confirma un web shell, el orden de contención es: aislar el host, preservar evidencia volátil, y recién después limpiar.
- Aislar de red el host afectado sin apagarlo, para preservar procesos y conexiones activas.
- Buscar archivos
.phpnuevos o modificados en el docroot en las últimas 72 horas, comparando contra control de versiones o backup conocido limpio. - Revisar conexiones salientes del host hacia IPs no habituales, consistentes con reclutamiento a botnet Mirai según lo reportado por The Hacker News.
- Rotar credenciales y claves almacenadas accesibles desde el proceso web comprometido (variables de entorno, archivos de configuración).
- Si el servicio califica como esencial bajo Ley 21.663, escalar la decisión de reporte a ANCI según lo definido en GV.
RC RecuperarVolver a operar y no repetirlo
La vuelta a producción solo procede si el host está reconstruido o verificadamente limpio, no simplemente parcheado sobre un posible compromiso previo.
- Reconstruir desde imagen limpia si se confirmó web shell o ejecución no autorizada; no basta con parchear PHP sobre el sistema comprometido.
- Validar la versión de PHP post-reconstrucción contra el inventario de ID antes de reabrir tráfico.
- Revisar el SLA de parcheo definido en GV: si esta vulnerabilidad tardó más de 48 horas en aplicarse, ajustar el proceso de gestión de parches, no solo el host puntual.
Llévatelo
Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.
La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.
Fuentes
- CISACritical Vulnerabilities in PHP Require Immediate Patching · 2026-10-21
- SANS ISCCritical PHP Vulnerability (CVE-2026-109618, CVE-2026-109619) [infocon yellow] · 2026-10-21
- SANS ISCPHP Vulnerability Wrap-Up · 2026-10-23
- CSA LabsPHP2Shell: Exploitation Before Disclosure for an AI-Found Flaw · 2026-10-23
- segu-infoObservación de una explotación tipo PHP2Shell con evidencia real de RCE · 2026-10-25
- The Hacker NewsPHP2Shell Exploit Attempts Hit Millions as Attackers Try to Deploy Mirai Malware · 2026-10-23
- The Hacker NewsPHP2Shell Exploitation Attempts Continue Amid Suspected N. Korea Global Scanning Activity · 2026-10-25
- The Hacker NewsPHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches · 2026-10-23
- Hispasec una-al-díaPHP publica parches de urgencia por dos fallos críticos PHP2Shell con intentos de explotación · 2026-10-21
¿Esto te aplica y no sabes por dónde partir?
Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.
Agendar diagnósticoRelacionado
CISA añade a KEV falla de Atlassian explotada en dos horas
CVE-2026-21589 permite a un atacante no autenticado leer archivos y directorios restringidos en productos Atlassian Data…
CISA suma PAN-OS, Cisco y Ahsay a su catálogo de explotación activa
Qilin e INC ya usan la falla de PAN-OS para saltarse el MFA, y Ahsay vuelve al catálogo porque su primer parche no cerró…
CISA agrega seis fallas activamente explotadas de Plex, Siemens y SiteGuard
El lote incluye una cadena de cuatro vulnerabilidades en Plex Media Server apodada "Plex2Shell" que permitiría ejecución…