PHP2Shell (CVE-2026-109618 y 109619)
1. Resumen ejecutivo
PHP2Shell exige parchear todos los servidores PHP en un plazo máximo de 72 horas, empezando por los expuestos a Internet en las primeras 24. Son dos vulnerabilidades críticas del núcleo de PHP (CVE-2026-109618 y CVE-2026-109619, CVSS v4.0 9.2) que permiten ejecutar código en remoto sin autenticación. Afectan prácticamente a cualquier web o API construida en PHP: WordPress, Drupal, Joomla, Magento, Laravel, Symfony, MediaWiki o phpBB, entre otras.
No es un riesgo teórico. Hubo intentos de explotación desde el 17 de octubre de 2026, cuatro días antes de su publicación, y existen exploits funcionales contra PHP 8.2 a 8.5. CISA las incluyó en su catálogo de vulnerabilidades explotadas (KEV) el 26 de octubre. El fallo está en el propio lenguaje, no en el código de la aplicación, así que una aplicación bien desarrollada también es vulnerable si corre sobre una versión de PHP sin parchear.
Como arquitecto de seguridad, mi recomendación a dirección es tratarlo como un cambio de emergencia, no como un ciclo normal de parcheo. Ese cambio tiene cuatro ejes:
- Conocer: inventario completo de dónde corre PHP, incluidos contenedores, appliances y proveedores.
- Contener: medidas compensatorias inmediatas donde no se pueda parchear el mismo día.
- Corregir: actualizar a las versiones corregidas y reiniciar todos los procesos.
- Comprobar: buscar indicios de compromiso desde el 17/10 y dejar evidencia auditable de cada paso.
Este caso ilustra bien el nuevo escenario de amenazas. Las vulnerabilidades se descubren con ayuda de IA y la ventana entre publicación y explotación se mide en horas. Los procesos de parcheo de 30 días ya no son suficientes para activos expuestos.
2. Contexto técnico
Ambos fallos están en la gestión interna de memoria de PHP durante el ciclo de vida de cada petición web.
| CVE | Debilidad (CWE) | Mecanismo | Impacto |
|---|---|---|---|
| CVE-2026-109618 | Corrupción de memoria por OOM (CWE-416) | Una petición multipart manipulada agota la memoria mientras los datos internos están a medio inicializar; la limpieza posterior trabaja con datos inválidos | RCE sin autenticación con privilegios del worker web |
| CVE-2026-109619 | Uso tras liberación, estado global obsoleto (CWE-416) | Tras un error fatal queda estado apuntando a memoria liberada; la siguiente petición en el mismo worker lo reutiliza | RCE sin autenticación y posible fuga de memoria |
| CVE-2026-115560 | Vía adicional por progreso de subida de sesión | Solo con una configuración inusual (cambio de serialize_handler en tiempo de ejecución) | RCE; probabilidad baja, sin parche aún |
Despliegues afectados: cualquier PHP que sirva peticiones web, es decir, Apache con mod_php, PHP-FPM, php-cgi, FrankenPHP y LiteSpeed, además de productos y appliances que incluyen PHP. El riesgo es máximo en mod_php, porque el exploit funciona con una sola petición antes de que se ejecute código de la aplicación.
Versiones afectadas y corregidas
| Rama | Versión corregida | Observaciones |
|---|---|---|
| 8.5 | 8.5.12 | Regresión conocida con SimpleXML (issue #24488) |
| 8.4 | 8.4.27 | Regresión conocida con SimpleXML (issue #24488) |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | |
| 7.4 a 8.1 | Sin release oficial | Backports de código fuente o parche del fabricante LTS; solución puente |
| 5.4 a 7.3 | Sin corrección | Fin de vida: migrar o aislar |
- Linux: las distribuciones aplican backports y mantienen el número de versión original. Se valida contra el aviso del fabricante (RHSA, DSA, USN), no contra
php -v. - Windows: usar las builds 8.x.y-1 publicadas el 26/10, que corrigen además CVE-2026-111497 en la librería Brotli incluida.
- Reinicio obligatorio: instalar el paquete no parchea los procesos en ejecución; el código vulnerable sigue en memoria hasta reiniciar FPM, Apache o el contenedor.
Estado de la amenaza (27/10/2026)
| Fecha | Hito |
|---|---|
| 26/10/2026 | CISA añade ambos CVE al catálogo KEV (plazo federal: 29/10). Exploits confirmados contra PHP 8.2–8.5 |
| 24/10/2026 | Explotación con éxito confirmada en honeypots con mod_php |
| 22/10/2026 | Intentos con descarga de segunda fase ligados a una botnet derivada de Mirai |
| 21/10/2026 | PHP publica las versiones corregidas; comienzan los escaneos masivos |
| 20/10/2026 | Filtración de los identificadores CVE antes de la divulgación coordinada |
| 17/10/2026 | Primer intento de explotación observado en honeypots |
Los PoC públicos aún dependen de combinaciones concretas de sistema, versión y servidor web. Esa dificultad es una ventana para parchear, no un motivo para esperar.
3. Objetivos del plan
El plan persigue un resultado medible: cero activos PHP vulnerables expuestos a Internet en 24 horas y cero en toda la organización en 7 días, con evidencia auditable.
Objetivo estratégico (gobierno)
Mantener el riesgo residual dentro del apetito de riesgo aprobado por dirección y demostrar diligencia ante auditores, clientes y reguladores (ENS, NIS2, DORA o sectoriales, según aplique).
Objetivos tácticos y operativos
| # | Objetivo | Métrica de éxito | Plazo |
|---|---|---|---|
| O1 | Inventariar el 100 % de los activos con PHP (servidores, contenedores, appliances, SaaS de terceros) | Inventario validado por cada responsable de plataforma | 12 h |
| O2 | Contener la exposición en activos que no se puedan parchear al momento | 100 % de activos expuestos con WAF, mitigación PHP o aislamiento | 24 h |
| O3 | Descartar o confirmar compromiso desde el 17/10/2026 | Informe de threat hunting firmado por cada activo P1/P2 | 48 h |
| O4 | Remediar con la versión corregida y reiniciar procesos | 100 % P1/P2 en 72 h; 100 % del parque en 7 días | 72 h / 7 d |
| O5 | Verificar la remediación de forma independiente | Reescaneo autenticado sin hallazgos de los CVE | 7 d |
| O6 | Formalizar las excepciones | Cada excepción con responsable, control compensatorio y fecha de caducidad | 7 d |
| O7 | Mejorar el proceso para la siguiente alerta crítica | Lecciones aprendidas aprobadas y acciones en el plan de mejora | 30 d |
Los plazos son una propuesta de referencia. Cada organización debe ajustarlos a su política de gestión de vulnerabilidades, pero para una vulnerabilidad en KEV con explotación activa no recomiendo superar las 72 horas en activos expuestos.
4. Análisis de riesgo
El riesgo inherente es crítico en activos expuestos a Internet y alto en activos internos. La amenaza es activa, el impacto es la toma de control del servidor y el ataque no requiere credenciales. Seguimos la lógica de ISO/IEC 27005 y MAGERIT: amenaza que explota una vulnerabilidad sobre un activo, con un impacto.
Amenazas
| ID | Amenaza | Actor | Técnica (MITRE ATT&CK) |
|---|---|---|---|
| A1 | Ejecución remota de código en servidor web | Ciberdelincuencia, botnets, APT | T1190 Exploit Public-Facing Application |
| A2 | Instalación de webshell y persistencia | Ciberdelincuencia, APT | T1505.003 Web Shell |
| A3 | Descarga de malware de segunda fase (botnets DDoS, criptominería) | Botnets automatizadas | T1105 Ingress Tool Transfer, T1496 |
| A4 | Robo o cifrado de datos (ransomware) | Grupos de ransomware | T1486, T1041 |
| A5 | Movimiento lateral desde la DMZ a la red interna | APT, ransomware | TA0008 Lateral Movement |
| A6 | Fuga de memoria con datos de sesión o credenciales | Atacante oportunista | T1212 |
| A7 | Ataque a través de proveedores o SaaS con PHP | Cadena de suministro | T1195 |
Debilidades y vulnerabilidades
| ID | Debilidad | Tipo |
|---|---|---|
| D1 | PHP sin parchear (CVE-2026-109618/109619) | Técnica |
| D2 | Versiones de PHP fuera de soporte (≤ 8.1) | Técnica / ciclo de vida |
| D3 | Inventario incompleto: activos olvidados, shadow IT, contenedores sin SBOM | Organizativa |
| D4 | Activos sin responsable (owner) identificado | Organizativa |
| D5 | Exposición innecesaria a Internet de paneles o aplicaciones internas | Arquitectura |
| D6 | Ausencia de WAF o de límites de tamaño de petición en el frontal | Arquitectura |
| D7 | Servidores web con salida libre a Internet (sin filtrado de egress) | Arquitectura de red |
| D8 | Falta de segmentación entre DMZ y red interna | Arquitectura de red |
| D9 | Escasa telemetría: sin EDR en servidores, sin auditoría de procesos | Detección |
| D10 | Ventanas de parcheo de 30 días o más para activos expuestos | Proceso |
Valoración
| Escenario | Probabilidad | Impacto | Riesgo inherente | Riesgo residual objetivo |
|---|---|---|---|---|
| Activo expuesto, mod_php, sin parchear | Muy alta | Muy alto | Crítico | Bajo (parcheado + WAF) |
| Activo expuesto, PHP-FPM, sin parchear | Alta | Muy alto | Crítico | Bajo |
| Activo interno con datos sensibles | Media | Alto | Alto | Bajo |
| PHP fuera de soporte sin parche posible | Muy alta | Muy alto | Crítico | Medio (aislado, con excepción formal) |
| Activo interno sin datos sensibles | Baja | Medio | Medio | Muy bajo |
El impacto afecta a las cinco dimensiones del ENS: confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad. Si el activo trata datos personales, una explotación confirmada es además una posible brecha a notificar en 72 horas según el art. 33 del RGPD.
5. Análisis DAFO
Las amenazas no se pueden controlar; las debilidades sí, y la primera es no saber con exactitud dónde corre PHP. El DAFO ayuda a explicar a dirección por qué la inversión debe ir a inventario, segmentación y velocidad de parcheo, no solo a más herramientas.
DAFO PHP2Shell: inventario y parcheo ágil marcan la diferencia
Debilidades · origen interno
- Inventario de software incompleto o desfasado
- Activos sin responsable claramente asignado
- PHP fuera de soporte (8.1 o anterior)
- Parcheo a 30 días también en activos expuestos
- Poca telemetría en servidores web (EDR, auditd)
- Salida libre a Internet desde la DMZ
Fortalezas · origen interno
- Escáneres de vulnerabilidades y EASM en uso
- WAF e IPS ya desplegados en el perímetro
- Proceso de cambio de emergencia definido
- SGSI o ENS con roles y responsables
- Automatización de sistemas (p. ej. Ansible)
- SOC con capacidad de threat hunting
Amenazas · origen externo
- Explotación activa y entrada en CISA KEV
- Exploits públicos que mejoran cada día
- Botnets que automatizan el escaneo masivo
- Ransomware y robo de datos tras el acceso
- Proveedores y SaaS con PHP sin parchear
- IA que acorta de días a horas la explotación
Oportunidades · origen externo
- Parches oficiales y de distribuciones listos
- Firmas WAF/IPS y plugins de escaneo publicados
- IOCs y guías públicas (CERT-EU, CISA)
- Ocasión para retirar PHP fuera de soporte
- Impulso a inventario continuo y SBOM
- IA defensiva para triaje y detección
Análisis DAFO · 4 cuadrantes, 24 factores
Las fortalezas reflejan lo habitual en una organización con un SGSI maduro; cada equipo debe sustituirlas por las suyas reales. La estrategia que se deriva es usar las fortalezas (escáneres, WAF, cambio de emergencia) para aprovechar las oportunidades (parches y firmas ya publicados) y cerrar las debilidades antes de que las amenazas las alcancen.
6. Plan de actuación paso a paso
El plan se ejecuta en siete fases, varias de ellas en paralelo. Se gestiona como cambio de emergencia (ITIL 4) y, si aparecen indicios de compromiso, pasa a gestión de incidente de seguridad.
Fase 0 · Activación y gobierno (hora 0)
- Declarar la alerta crítica, abrir el cambio de emergencia y nombrar un coordinador.
- Convocar al comité de cambios de emergencia (ECAB): Seguridad, Sistemas, Desarrollo, responsables de plataforma y, si aplica, el Responsable de Seguridad ENS y el DPD.
- Fijar un canal único de coordinación y un parte de situación cada 4–8 horas.
- Congelar cambios no urgentes sobre los servidores afectados.
Fase 1 · Detección e inventario (0–12 h)
- Superficie externa: herramienta EASM o flujo open source (Subfinder/Amass + httpx con detección de tecnología + Nuclei) para localizar todo lo expuesto que usa PHP.
- Servidores: escaneo autenticado (Nessus, Qualys, Rapid7, OpenVAS) y consulta del inventario de software (CMDB, agentes, Wazuh).
- Comprobación manual en Linux:
php -v; php -i | grep -E "Server API|Thread Safety"
ps -eo pid,user,cmd | grep -Ei "php-fpm|php-cgi|lsphp|frankenphp|httpd|apache2"
apachectl -M 2>/dev/null | grep -i php
rpm -qa | grep -i php # o: dpkg -l | grep -i php- Contenedores y Kubernetes/OpenShift: listar imágenes desplegadas y escanearlas todas con Trivy o Grype, no solo las que se llaman "php". Generar SBOM con Syft.
- Windows/IIS: buscar
php.exey revisar la configuración FastCGI. - Terceros: pedir a proveedores y SaaS su estado frente a los CVE.
- Consolidar el inventario: activo, entorno, SAPI, versión y revisión de paquete, exposición, datos tratados, responsable y estado.
Fase 2 · Priorización (en paralelo con la fase 1)
| Prioridad | Criterio | Plazo de remediación |
|---|---|---|
| P1 | Expuesto a Internet con mod_php, o versión fuera de soporte | Contención inmediata, parche < 24 h |
| P2 | Expuesto a Internet con FPM, CGI, LiteSpeed o FrankenPHP | < 24–48 h |
| P3 | Interno con datos sensibles o accesible por terceros | < 72 h |
| P4 | Interno sin datos sensibles; desarrollo y CI/CD | < 7 días |
Fase 3 · Contención (P1/P2 que no se puedan parchear en el acto)
- Configuración PHP forzada por el administrador (no sobrescribible por la aplicación), y reinicio de todos los workers:
; Pool PHP-FPM
php_admin_value[memory_limit] = -1
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[fatal_error_backtraces] = off ; solo PHP 8.5
php_admin_value[post_max_size] = 8M- Compensar el
memory_limit=-1con límites de memoria por cgroup o contenedor (nunca con RLIMIT_AS). - Frontal: WAF con firmas PHP2Shell, límite de tamaño de petición, número de campos y partes multipart; bloquear multipart en aplicaciones que no suben ficheros.
- IPS/IDS: activar firmas Suricata o Snort.
- Red: filtrado de salida desde servidores web, restricción por IP o VPN de lo que no deba ser público y aislamiento temporal de lo que no admita mitigación.
Fase 4 · Investigación de compromiso (desde el 17/10/2026)
- Buscar en logs de WAF y proxy peticiones multipart con
PHP_SESSION_UPLOAD_PROGRESS, el user-agentphp2shell-scan, marcadores comoPHP2SHELL_CONFIRMEDy los IOCs publicados. - Buscar en logs de servidor ráfagas de errores
Segmentation faultoSIGSEGVen workers. - En EDR o auditd: procesos
php-fpm,httpdoapache2que lanzansh,id,uname,wgetocurl. - Revisar ficheros
.phpmodificados y binarios nuevos en/tmp,/var/tmpy/dev/shmdesde el 17/10. - Si hay indicios: capturar memoria y disco antes de reiniciar, aislar el host, escalar a incidente y notificar (CCN-CERT/INCIBE-CERT, autoridad de control RGPD, CSIRT NIS2 según corresponda). Un equipo comprometido se reconstruye; no se parchea encima.
- Recordar que la ausencia de logs no demuestra ausencia de compromiso.
Fase 5 · Remediación definitiva
- Actualizar a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido del fabricante (validado contra su aviso).
- Windows: builds 8.x.y-1. Contenedores: reconstruir la imagen, reescanear y redesplegar.
- Versiones fuera de soporte: backport del fabricante como solución puente y plan de migración con fecha.
- Appliances y SaaS: aplicar el parche del fabricante o exigir su compromiso por escrito.
- Pruebas de no regresión, atentas a la incidencia de SimpleXML en 8.4.27 y 8.5.12.
- Reiniciar todos los procesos PHP y confirmar que no queda ninguno anterior al parche.
Fase 6 · Verificación independiente
- Reescaneo autenticado sin hallazgos de los CVE en todo el inventario.
- Comprobar versión y hora de arranque de cada proceso PHP en ejecución.
- Revisión por una persona distinta de quien aplicó el cambio (segregación de funciones).
Fase 7 · Cierre y mejora continua
- Formalizar excepciones con aceptación del riesgo por su propietario.
- Retirar las mitigaciones temporales que ya no sean necesarias, salvo
session.upload_progress.enabled=0hasta que se corrija CVE-2026-115560. - Informe final, lecciones aprendidas y actualización de procedimientos, playbooks y CMDB.
7. Controles y mapeo normativo
Un mismo conjunto de controles cubre a la vez ENS, ISO 27001, NIST, COBIT e ITIL. No hay que hacer el trabajo cinco veces: se ejecuta una vez y la evidencia se reutiliza en cada marco.
| Control | ENS (RD 311/2022) | ISO 27001:2022 | NIST CSF 2.0 | NIST SP 800-53 r5 | COBIT 2019 / 5 | ITIL 4 (práctica) |
|---|---|---|---|---|---|---|
| Inventario de activos y software | op.exp.1 | 5.9 | ID.AM-01, ID.AM-02 | CM-8 | BAI09, BAI10 | Gestión de activos TI; Gestión de la configuración |
| Inteligencia de amenazas y vigilancia de alertas | op.mon.3 | 5.7 | ID.RA-02 | SI-5, PM-16 | APO12.01 | Gestión de la seguridad de la información |
| Análisis y tratamiento del riesgo | op.pl.1 | Cl. 6.1.2, 6.1.3, 8.2, 8.3 | GV.RM, ID.RA-05 | RA-3 | EDM03, APO12 | Gestión de riesgos |
| Gestión de vulnerabilidades y parcheo | op.exp.4 | 8.8 | ID.RA-01, PR.PS-02 | RA-5, SI-2 | APO12, DSS05 | Gestión de versiones; Gestión del despliegue |
| Componentes fuera de soporte | op.exp.4 | 8.8, 5.9 | PR.PS-02 | SA-22 | BAI09 | Gestión de activos TI |
| Configuración segura (bastionado de php.ini) | op.exp.2, op.exp.3 | 8.9 | PR.PS-01 | CM-2, CM-6, CM-7 | BAI10 | Gestión de la configuración del servicio |
| Cambio de emergencia | op.exp.5 | 8.32 | PR.PS-01 | CM-3 | BAI06 | Habilitación del cambio |
| Perímetro, WAF y protección de aplicaciones web | mp.com.1, mp.s.2 | 8.20, 8.21, 8.23 | PR.IR-01 | SC-7 | DSS05.02 | Gestión de infraestructura y plataforma |
| Segmentación y filtrado de salida | mp.com.4 | 8.22 | PR.IR-01 | SC-7 | DSS05.02 | Gestión de infraestructura y plataforma |
| Registro, monitorización y detección | op.exp.8, op.mon.1 | 8.15, 8.16 | DE.CM-01, DE.CM-09, DE.AE | AU-6, SI-4 | DSS05.07 | Monitorización y gestión de eventos |
| Protección frente a código dañino | op.exp.6 | 8.7 | DE.CM-09 | SI-3 | DSS05.01 | Gestión de la seguridad de la información |
| Respuesta y notificación de incidentes | op.exp.7, op.exp.9 | 5.24 a 5.28 | RS.MA, RS.AN, RS.MI, RS.CO | IR-4, IR-5, IR-6 | DSS02, DSS03 | Gestión de incidentes; Gestión de problemas |
| Proveedores y servicios externos | op.ext.1, op.ext.2 | 5.19 a 5.22 | GV.SC | SA-9, SR-3 | APO10 | Gestión de proveedores |
| Desarrollo seguro y dependencias | mp.sw.1, mp.sw.2 | 8.25, 8.28, 8.29 | PR.PS-06 | SA-11 (y SSDF SP 800-218) | BAI03 | Desarrollo y gestión de software |
| Continuidad y disponibilidad | op.cont.2 | 5.30 | RC.RP | CP-2 | DSS04 | Gestión de la continuidad del servicio |
| Mejora continua | Art. 26 (mejora continua) | Cl. 10.1, 10.2 | ID.IM | CA-7 | MEA01 | Mejora continua |
Guías de apoyo: NIST SP 800-40 r4 (gestión de parches en la empresa), NIST SP 800-61 r3 (respuesta a incidentes) y las guías CCN-STIC del CCN-CERT para la aplicación del ENS.
ISO/IEC 42001 (sistemas de gestión de IA)
ISO 42001 aplica en dos situaciones concretas de este caso:
- Sistemas de IA que corren sobre PHP. Chatbots, portales con IA generativa o frontales de RAG construidos en PHP heredan la vulnerabilidad. Hay que incluirlos en el inventario y en la evaluación de riesgos del sistema de IA (cláusulas 6.1 y 8.2) y en los controles de recursos y operación del Anexo A (A.4 recursos del sistema de IA, A.6 ciclo de vida y monitorización, A.10 relación con terceros).
- Uso de IA en la defensa. Si el SOC usa IA para triaje, análisis de logs o generación de reglas, deben respetarse los controles de uso responsable (A.9): supervisión humana de las decisiones, no enviar logs con datos personales a servicios no autorizados y registrar qué recomendaciones de la IA se aplicaron.
Este caso confirma además un cambio en el modelo de amenazas: la IA acelera tanto el descubrimiento como la explotación, y eso debe reflejarse en el análisis de riesgos y en los plazos de parcheo.
ISACA
Más allá de COBIT, el enfoque se apoya en tres referencias de ISACA:
- Risk IT / CRISC: ciclo de identificación, evaluación, respuesta (mitigar, transferir, aceptar, evitar) y monitorización del riesgo, con dueño del riesgo identificado.
- CISM: gobierno del programa de seguridad y gestión de incidentes (dominios 1 y 4).
- ITAF (marco de auditoría de TI): la evidencia debe ser suficiente, fiable y pertinente para que un auditor pueda verificar la remediación sin repetir el trabajo.
8. Evidencias de remediación
Un activo se da por remediado solo cuando hay evidencia objetiva, fechada y verificada por alguien distinto de quien aplicó el cambio. "Está parcheado" sin prueba no cuenta. Las evidencias se archivan en el expediente del cambio y alimentan la Declaración de Aplicabilidad (ISO 27001) y la auditoría del ENS.
| Fase | Evidencia | Formato | Criterio de aceptación |
|---|---|---|---|
| 0 · Activación | Registro del cambio de emergencia y acta del ECAB | Ticket ITSM, acta firmada | Fecha y hora, responsables y alcance definidos |
| 1 · Inventario | Inventario de activos PHP con versión, SAPI, exposición y responsable | Hoja de cálculo o CMDB exportada | Cada activo tiene un responsable que lo ha validado |
| 1 · Inventario | Informe del escaneo inicial (EASM y autenticado) | PDF o CSV de la herramienta | Fecha, alcance y credenciales usadas documentados |
| 2 · Priorización | Matriz de priorización P1–P4 | Tabla en el expediente | Criterios aplicados de forma coherente |
| 3 · Contención | Configuración PHP antes y después; reglas WAF/IPS activas; cambios de firewall | Diff de ficheros, captura de la consola, export de reglas | Cambio trazado a ticket y reinicio de workers verificado |
| 4 · Investigación | Informe de threat hunting por activo P1/P2 | Informe con consultas usadas y resultados | Periodo cubierto desde el 17/10/2026; conclusión explícita: comprometido / no hay indicios |
| 4 · Investigación | Si hay incidente: cadena de custodia, volcados de memoria, notificaciones | Formularios, hashes, acuses de recibo | Hashes SHA-256 de cada evidencia; plazos legales cumplidos |
| 5 · Remediación | Versión instalada y revisión del paquete; aviso del fabricante aplicado | Salida de rpm -q/dpkg -l/php -v con fecha y host | Coincide con la versión corregida o el aviso RHSA/DSA/USN |
| 5 · Remediación | Procesos PHP reiniciados | Salida de ps -o lstart o reinicio del pod | Ningún proceso arrancado antes del parche |
| 5 · Remediación | Resultado de pruebas de no regresión | Informe de QA | Aprobado por el responsable de la aplicación |
| 6 · Verificación | Reescaneo autenticado sin los CVE | Informe de la herramienta | 0 hallazgos de CVE-2026-109618/109619 en el alcance |
| 6 · Verificación | Revisión independiente | Registro de la persona que verifica | Segregación de funciones respecto a quien ejecutó |
| 7 · Cierre | Registro de excepciones y aceptación de riesgo | Formulario firmado por el dueño del riesgo | Control compensatorio y fecha de caducidad definidos |
| 7 · Cierre | Informe final y lecciones aprendidas | Documento aprobado | Acciones de mejora con responsable y fecha |
Para que la evidencia sea válida ante un auditor (criterios ITAF de ISACA y requisitos de auditoría del ENS):
- Suficiente: cubre el 100 % del inventario, no una muestra.
- Fiable: generada por la herramienta o el sistema, con fecha, hora y host visibles; no transcrita a mano.
- Pertinente: demuestra el control exacto (versión corregida y proceso reiniciado), no solo que el paquete se descargó.
- Íntegra: almacenada en un repositorio con control de acceso y, en caso de incidente, con hash y cadena de custodia.
9. Indicadores, excepciones y lecciones aprendidas
Dirección debe poder ver en un solo cuadro cuánto riesgo queda y a qué ritmo baja. Propongo pocos indicadores, medidos cada día hasta el cierre.
Indicadores
| Tipo | Indicador | Meta |
|---|---|---|
| KPI | % de activos PHP inventariados con responsable asignado | 100 % en 12 h |
| KPI | % de activos expuestos parcheados o contenidos | 100 % en 24 h |
| KPI | % del parque total remediado y verificado | 100 % en 7 días |
| KPI | Tiempo medio de remediación (MTTR) en activos P1/P2 | < 48 h |
| KRI | Nº de activos expuestos aún vulnerables | 0 |
| KRI | Nº de activos con PHP fuera de soporte | Tendencia a 0, con plan fechado |
| KRI | Nº de activos descubiertos que no estaban en el inventario | Indica madurez del inventario; debe bajar en cada alerta |
| KRI | Nº de excepciones abiertas y vencidas | 0 vencidas |
Gestión de excepciones
Cuando un activo no se puede parchear (fuera de soporte, appliance sin parche, aplicación crítica que no tolera la regresión), se abre una excepción formal con:
- Justificación técnica y de negocio.
- Controles compensatorios aplicados y verificados (aislamiento, WAF, mitigación PHP, monitorización reforzada).
- Riesgo residual valorado y aceptado por escrito por el dueño del riesgo, no por el técnico.
- Fecha de caducidad y plan de salida (parche, migración o retirada).
Lecciones aprendidas
Al cierre conviene revisar al menos estas preguntas:
- ¿Cuánto tardamos en saber dónde teníamos PHP? Si fueron días, el inventario no es fiable.
- ¿Cuántos activos aparecieron sin responsable o sin estar en la CMDB?
- ¿Las imágenes de contenedor se reconstruyen solas cuando cambia la imagen base?
- ¿Los servidores web tienen EDR y salida a Internet restringida?
- ¿Nuestra política de parcheo distingue entre activos expuestos con vulnerabilidades en KEV y el resto?
Las respuestas deben convertirse en acciones del plan de mejora con responsable y fecha. Mis recomendaciones mínimas: inventario continuo con EASM, SBOM en el pipeline de CI/CD, reconstrucción automática de imágenes, política de versiones de PHP soportadas y un plazo máximo de 72 horas para vulnerabilidades críticas explotadas en activos expuestos.
10. Referencias
- PHP: aviso oficial y versiones corregidas
- CERT-EU, Security Advisory 2026-018
- Tenable: preguntas frecuentes sobre php2shell
- Rapid7: análisis técnico y mitigaciones
- Arctic Wolf Labs: explotación activa e IOCs
- Laravel Forge: tabla de versiones y backports
- Black Kite: CVE-2026-115560
- Real Decreto 311/2022, Esquema Nacional de Seguridad; guías CCN-STIC del CCN-CERT
- ISO/IEC 27001:2022, ISO/IEC 27005:2022 e ISO/IEC 42001:2023
- NIST Cybersecurity Framework 2.0; NIST SP 800-53 r5, SP 800-40 r4, SP 800-61 r3 y SP 800-218 (SSDF)
- ISACA: COBIT 2019, Risk IT Framework e ITAF
- AXELOS/PeopleCert: ITIL 4
Comentarios
Publicar un comentario