Alerta crítica de seguridad en PHP (21 de octubre de 2026): análisis de CVE-2026-109618 y CVE-2026-109619, versiones afectadas y guía de actualización oficial

La primera vulnerabilidad, registrada como CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), reside en el mecanismo de aborto por falta de memoria (Out-Of-Memory) del Zend Engine. Cuando un script o una petición entrante alcanza el límite configurado en la directiva memory_limit de php.ini, PHP no realiza un retorno limpio convencional, sino que invoca una interrupción drástica de contexto utilizando la función longjmp() de C.

Durante el procesamiento de peticiones HTTP complejas —particularmente aquellas con cabeceras multipart/form-data y seguimiento de progreso de carga de archivos (session.upload_progress)— un límite de memoria alcanzado a mitad del parsing interrumpe la ejecución antes de que las estructuras globales de la petición se inicialicen por completo.

El fallo crítico se produce durante la fase posterior de limpieza (request shutdown y cleanup routine): el motor asume erróneamente que los descriptores y punteros de memoria están en un estado consistente e intenta liberar o dereferenciar direcciones de memoria parcialmente inicializadas. Esta condición desata una sobreescritura de memoria arbitraria (heap corruption) que un atacante puede sincronizar para redirigir punteros de ejecución y tomar el control total del proceso.

La segunda vulnerabilidad, identificada como CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), explota la arquitectura de procesos persistentes (workers) que caracteriza a despliegues de alto rendimiento como PHP-FPM o módulos integrados de servidor web.

En estos entornos, los procesos de los workers no mueren al terminar de responder una petición; se mantienen vivos para recibir solicitudes subsiguientes. Debido al manejo abrupto de errores fatales mediante longjmp(), ciertas variables globales del motor conservan punteros que apuntan a bloques de memoria que ya fueron desasignados (liberados) al finalizar la petición abortada.

Cuando el mismo worker acepta una nueva petición entrante, accede a este estado global residual antes de que el ciclo de inicialización estándar lo sobrescriba (condición de Use-After-Free). Un atacante puede aprovechar esta ventana para dos propósitos devastadores: filtrar contenido de memoria perteneciente a peticiones de otros usuarios procesadas por ese mismo worker (exfiltrando tokens de sesión, credenciales de bases de datos, claves de APIs y secretos de entorno .env), o manipular la disposición del heap para ejecutar código malicioso en el servidor.

El alcance de ambas vulnerabilidades es extraordinariamente amplio debido a que el diseño del manejo de errores con longjmp() en el Zend Engine se remonta a más de una década de código base. Todas las versiones comprendidas entre PHP 5.4 y PHP 8.5.11 se encuentran afectadas en sus instalaciones predeterminadas.

El equipo oficial de PHP (php.net) ha publicado los parches de emergencia exclusivamente para las ramas activas con soporte oficial vigente. Las versiones corregidas que deben desplegarse hoy mismo son:

• Rama PHP 8.5: Actualizar a PHP 8.5.12 • Rama PHP 8.4: Actualizar a PHP 8.4.27 • Rama PHP 8.3: Actualizar a PHP 8.3.36 • Rama PHP 8.2: Actualizar a PHP 8.2.35

Situación crítica para versiones End-Of-Life (EOL): Las versiones PHP 8.1, 8.0, 7.x y 5.x ya no cuentan con soporte oficial por parte de The PHP Group y no recibirán instaladores ni binarios compilados automáticos desde php.net. Aunque existen parches de código fuente (diffs) distribuidos por la comunidad, quienes operen estas versiones en servidores expuestos a internet deben recurrir a repositorios con soporte extendido (como Debian Extended LTS, AlmaLinux/CloudLinux ELevate o TuxCare) o emprender una migración urgente a una versión moderna.

Para aplicar la solución definitiva, es imprescindible actualizar los paquetes binarios desde los repositorios oficiales de tu sistema operativo o reconstruir las imágenes de contenedor base:

A) Servidores Ubuntu / Debian (usando el repositorio oficial de Ondřej Surý o repositorios del sistema): Actualiza la lista de paquetes y aplica la actualización específica para PHP y sus extensiones FPM: sudo apt update sudo apt --only-upgrade install php8.3 php8.3-fpm php8.3-cli php8.3-common php8.3-opcache sudo systemctl restart php8.3-fpm sudo systemctl reload nginx # o apache2

B) Servidores RHEL / Rocky Linux / AlmaLinux (usando Remi's RPM repository): Ejecuta la actualización del gestor dnf y reinicia el demonio del pool de workers: sudo dnf check-update sudo dnf upgrade "php*" sudo systemctl restart php-fpm

C) Entornos contenerizados (Docker y Kubernetes): Actualiza tu Dockerfile para utilizar la última versión de parche publicada hoy en Docker Hub (por ejemplo, 'FROM php:8.3.36-fpm-alpine'). Es crucial forzar una reconstrucción sin caché para asegurar que no se reutilicen capas antiguas: docker build --no-cache -t mi-app-backend:latest . docker compose up -d --force-recreate En clústeres de Kubernetes, actualiza el tag del contenedor en tu Deployment y aplica un rollout restart para reciclar todos los pods activos.

D) Verificación del parche aplicado: Verifica en la línea de comandos que la versión instalada coincida con la entrega oficial: 'php -v'. Si utilizas PHP-FPM, comprueba también la versión reportada a través de phpinfo() en un archivo temporal protegido o mediante el socket de telemetría de php-fpm.

Si tu organización requiere una ventana de mantenimiento planificada o pruebas de regresión que tomen varias horas antes del reinicio, aplica de inmediato estas medidas de contingencia para reducir la superficie de ataque perimetral:

1. Desactivar el tracking de subida en php.ini: La directiva session.upload_progress.enabled es uno de los disparadores clave identificados en los vectores de ataque OOM. Si tu aplicación no depende de esta función, edita tu php.ini y establécela en Off: session.upload_progress.enabled = Off Luego aplica una recarga rápida de la configuración (graceful reload).

2. Reglas de inspección en WAF (Web Application Firewall): Configura tu WAF (Cloudflare, AWS WAF, Fastly o ModSecurity en Nginx) para inspeccionar y descartar solicitudes multipart/form-data con payloads malformados, valores de cabeceras inusualmente extensos o variables de sesión que intenten simular cuotas desproporcionadas.

3. Monitoreo de caídas de workers (SIGSEGV): Revisa los registros del sistema con 'journalctl -u php-fpm' o inspecciona /var/log/php-fpm.log buscando caídas anormales con códigos de señal 11 (Segmentation fault) o señal 7 (Bus error). Una ráfaga recurrente de estos errores suele indicar intentos de heap spraying o explotación.

4. Auditoría de procesos hijos sospechosos: Un intento de RCE consumado habitualmente intentará invocar un shell interactivo. Monitorea mediante herramientas de observabilidad o comandos como 'ps aux | grep -E "(sh|bash|nc|curl|wget)"' si existen procesos hijos derivados del usuario web del sistema (www-data, nginx, apache).