01 · Contexto
Qué está ocurriendo
Hechos verificados, 21 de octubre de 2026. El 21 de octubre se publicaron CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades críticas del runtime PHP. Google Cloud informa severidad CVSS 9,2 y posibles consecuencias de ejecución remota sin autenticación y divulgación de memoria. Las versiones corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12; PHP 8.1 y anteriores no recibirán estos parches del proyecto. El aviso de PHP para la primera vulnerabilidad confirma ejecución remota en Apache mod_php; para FPM describe susceptibilidad, pero no un exploit completo demostrado. Esa diferencia importa: no corresponde afirmar que todas las configuraciones tienen idéntica explotabilidad. Google distingue los servicios con actualización automática de aquellos que requieren reconstruir imágenes y redesplegar. El anuncio no demuestra que una organización chilena específica haya sido comprometida.
02 · Impacto
Por qué importa
Interpretación editorial. Este es un problema que puede quedar fuera de una revisión centrada en dependencias de Composer: la exposición relevante incluye la imagen base, el motor que ejecuta el servicio y las copias aún activas del despliegue. Para un equipo con aplicaciones heredadas, la dificultad no es solamente obtener un paquete actualizado, sino encontrar todos los lugares donde sigue ejecutándose PHP y demostrar que la versión vulnerable dejó de atender tráfico. La prioridad sugerida es revisar primero servicios públicos y aplicaciones con información sensible, sin confundir prioridad con evidencia de intrusión.
03 · Recomendaciones
Qué conviene hacer
- Recomendaciones propias. Abrir un registro de remediación por servicio que identifique responsable, versión efectiva en ejecución, entorno, fecha de despliegue y evidencia de verificación. Contrastar ese inventario con repositorios, registros de contenedores y plataformas de hosting; no dar por cerrada la revisión con una búsqueda de archivos en el código.
- Preparar pruebas de compatibilidad de sesiones, formularios, cargas de archivos, tareas programadas y extensiones antes de promover la nueva imagen. Acordar una ventana de cambio y un mecanismo de recuperación que no reintroduzca silenciosamente una versión vulnerable. Si un proveedor administra el runtime, pedir evidencia de actualización y no solo una declaración genérica de protección.
- Mantener las medidas perimetrales como defensa adicional, no como reemplazo del parche. Evitar cambiar límites de memoria indiscriminadamente: una medida transitoria puede alterar disponibilidad y requiere evaluación técnica específica. Después del despliegue, comprobar los procesos realmente activos, revisar errores y conservar los registros necesarios para investigar comportamientos anómalos. El cierre debe sustentarse en evidencia de ejecución corregida, no únicamente en el ticket de cambio.