CISA mete PHP2Shell en el KEV: plazo federal el 29 de octubre
CISA añadió CVE-2026-109618 y CVE-2026-109619 al KEV el 26 de octubre. El plazo federal vence el 29; además del parche, las agencias deben valorar exposición y triage forense.

CISA incorporó el 26 de octubre CVE-2026-109618 y CVE-2026-109619 al catálogo KEV, que reúne vulnerabilidades con evidencia de explotación conocida. La entrada fija el 29 de octubre como fecha límite de remediación para las agencias federales cubiertas y marca que hace falta triage forense. El cambio eleva la prioridad para quien ejecute PHP expuesto a peticiones web, aunque no aparezca en un servidor llamado “PHP” en el inventario.
PHP había corregido ambos fallos el 21 de octubre en 8.2.35, 8.3.36, 8.4.27 y 8.5.12; el 26 no hubo un parche nuevo. El cambio del día es la clasificación de riesgo y el triage forense, mientras la corrección técnica sigue siendo actualizar el runtime que mantiene el proveedor.
-InfraCrew dice: El inventario que solo busca paquetes con nombre PHP deja fuera justo los runtimes que llegan empaquetados dentro de una aplicación.-
De “parchea ya” a “comprueba si hubo intrusión”
El aviso de CISA del 21 de octubre decía que aún no había observado explotación. La entrada posterior en KEV no borra esa fotografía: la evidencia disponible cambió. Es una distinción útil para equipos que archivaron la alerta inicial o dejaron el ticket cerrado tras desplegar la corrección.
Los dos fallos permiten ejecución remota de código sin autenticación en condiciones que dependen de la ruta vulnerable. CVE-2026-109618 parte de una corrupción asociada a errores de memoria agotada; CVE-2026-109619 afecta a estado interno de una petición anterior que puede seguir vivo en un worker. No son dos nombres para el mismo bug, aunque se corrigieran en la misma tanda de versiones y ambos puedan acabar dando ejecución de código.
La entrada de CISA registra una fecha límite federal del 29 de octubre y marca triage forense. Ese plazo proviene del marco de gestión de vulnerabilidades para organismos federales; no es una orden legal general para cualquier empresa. Para el resto, la inclusión sirve como señal de que no basta con instalar el parche y cerrar la alerta: hay que valorar la exposición real y revisar si existen indicios de uso antes de la remediación.
-InfraCrew dice: “Actualizado” contesta qué versión corre ahora; no contesta qué ocurrió con las peticiones de la semana pasada.-
El PHP que no sale en el inventario
PHP mantiene varios modos de ejecución, y el aviso del proyecto incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed entre los servicios que procesan solicitudes. El riesgo no se limita a una máquina virtual tradicional: puede vivir dentro de una imagen de contenedor, una appliance o el runtime que distribuye un producto. CISA también advierte que PHP puede ser una dependencia interna y no resultar evidente a simple vista.
Por eso el primer paso útil es rastrear versiones en hosts y contenedores, paquetes de distribución, paneles y productos que traen sus propios componentes. Comprueba el proceso que atiende la petición, no solo el paquete que aparece en la consola del sistema. Las ramas corregidas por el proyecto son 8.2.35, 8.3.36, 8.4.27 y 8.5.12; PHP 8.1 y anteriores ya no reciben actualizaciones upstream, aunque una distribución o proveedor con soporte pueda ofrecer un backport propio.
Después, identifica qué versión está activa en cada worker y qué artefacto la contiene. Actualizar una imagen base sin reconstruir y desplegar la aplicación no cambia los workers que siguen ejecutándose; lo mismo ocurre cuando una instalación mantiene una segunda rama para procesos batch o tareas auxiliares. La comprobación debe terminar en la versión efectiva del runtime, no en el estado de un repositorio o de un pipeline.
-InfraCrew dice: El contenedor corregido que nadie volvió a desplegar es un buen ejemplo de cumplimiento en el dashboard y cero cambios en producción.-
Parche y triage van en paralelo
Las versiones upstream corregidas son la solución completa. Si el sistema operativo o la aplicación empaqueta PHP con numeración propia, sigue su aviso y confirma el backport; una numeración distinta no demuestra que el fallo siga presente. Para ramas antiguas sin soporte del proyecto, incluye una ruta de actualización en el plan.
En paralelo, conserva registros y determina qué activos estuvieron expuestos con versiones afectadas. El triage forense no declara comprometido cada sistema: busca evidencia para decidir si hace falta contención, rotar secretos o ampliar la investigación. Las agencias sujetas al plazo deben documentarlo; para cualquier operador, evita que un parche tape una intrusión previa.
La entrada KEV deja como desconocido el uso en ransomware; no hay base para atribuir estos fallos a una campaña concreta. La señal firme es la explotación conocida que motivó su inclusión, con fecha límite y triage exigidos en el ámbito federal. Actualizar, verificar el runtime y revisar la exposición son tareas distintas que deben avanzar en paralelo.
Diccionario de la Crew
KEV — Catálogo de CISA con vulnerabilidades para las que existe evidencia de explotación conocida.
PHP-FPM — Gestor de procesos PHP que atiende peticiones FastCGI detrás de un servidor web.
Backport — Corrección trasladada por un proveedor a una rama que mantiene, sin cambiar necesariamente a la versión upstream más reciente.
Triage forense — Revisión inicial de evidencia para determinar si un activo pudo haber sido comprometido y qué investigación adicional necesita.
Fuentes
CISA — catálogo Known Exploited Vulnerabilities (JSON)
PHP.net — archivo de avisos de seguridad de 2026


