Análisis de las vulnerabilidades críticas RCE en PHP (CVE-2026-109618 y CVE-2026-109619): Qué ocurrió y cómo asegurar tus servidores

Análisis de las vulnerabilidades críticas RCE en PHP (CVE-2026-109618 y CVE-2026-109619): Qué ocurrió y cómo asegurar tus servidores
La semana pasada, el ecosistema web vivió una de las jornadas de actualización más urgentes de los últimos años. El miércoles 21 de octubre de 2026, el equipo de seguridad de PHP lanzó parches de emergencia para corregir dos vulnerabilidades críticas (CVSS 9.2) que permitían la ejecución remota de código (RCE) sin necesidad de autenticación.
Lo más delicado de este incidente no es un fallo en un paquete de terceros o en la lógica de un framework, sino que el problema reside directamente en el núcleo (core) de PHP y se ejecuta durante el procesamiento inicial de la petición HTTP, incluso antes de que el código de nuestra aplicación (como el ciclo de vida de Laravel) llegue a iniciarse.
En este artículo repaso qué ocurrió exactamente a nivel técnico, qué entornos se vieron afectados y qué pasos son imprescindibles para garantizar que tu infraestructura esté completamente protegida.
¿Qué falló exactamente en el motor de PHP?
Cualquier instalación de PHP que sirva peticiones web se vio afectada: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Es decir, prácticamente la totalidad de los entornos de producción donde desplegamos aplicaciones Laravel y APIs hoy en día.
Aunque el riesgo más alto se registró en mod_php (donde existía un exploit funcional capaz de dispararse antes de ejecutar una sola línea de código de la aplicación), ningún entorno quedaba exento. Los dos fallos identificados son:
1. Corrupción de memoria por falta de recursos (OOM): CVE-2026-109618
(GHSA-w8hw-w9fx-j79w)
El gestor de falta de memoria (Out-Of-Memory) podía interrumpir la ejecución de PHP en un momento crítico: cuando las estructuras de datos internas de la petición estaban solo parcialmente inicializadas. Al ejecutarse posteriormente el proceso de limpieza de la petición (request cleanup), PHP trataba esos datos inválidos o corruptos como si fueran punteros válidos, abriendo la puerta a la ejecución arbitraria de código.
2. Persistencia de estado global obsoleto: CVE-2026-109619
(GHSA-6wmf-4rv5-p3rp)
En arquitecturas donde los workers reutilizan procesos para atender múltiples peticiones secuenciales, un estado interno perteneciente a una petición podía sobrevivir después de que su memoria hubiera sido liberada. Una petición posterior atendida por ese mismo worker podía acceder y utilizar ese estado residual (stale state) antes de que el ciclo normal de inicialización lo restableciera.
Versiones parcheadas y el estado de versiones antiguas
Para corregir ambos vectores de ataque, se publicaron de forma inmediata las siguientes versiones:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

¿Qué pasa con PHP 8.1 o versiones anteriores?
Oficialmente, PHP 8.1 e inferiores ya no reciben soporte directo del proyecto PHP. Sin embargo, dada la gravedad crítica de la vulnerabilidad, el equipo de seguridad publicó de forma excepcional backports mínimos en código fuente para PHP 7.4, 8.0 y 8.1, además de los parches distribuidos por proveedores LTS (como los repositorios de Ubuntu o el PPA de Ondřej Surý). Aun así, si todavía mantienes proyectos en 8.1 o inferior, este incidente es el recordatorio definitivo de que debes planificar la migración a una rama activa cuanto antes.
Impacto y actuación en el ecosistema Laravel (Forge, Cloud y Vapor)
Si gestionas servidores de producción para tus proyectos o los de tus clientes, el procedimiento varía según la plataforma de despliegue:
Servidores gestionados con Laravel Forge
En Forge la actualización no es automática y requiere intervención manual en cada servidor:

1. Accede al panel de cada servidor en Forge y pulsa en Update PHP para tus versiones instaladas (8.2, 8.3, 8.4 u 8.5).
2. Si experimentas demoras o bloqueos desde el panel, conéctate directamente por SSH al servidor y actualiza los paquetes del sistema (sudo apt update && sudo apt upgrade) para descargar los binarios parcheados, reiniciando después el servicio php8.x-fpm.
3. Verifica siempre por consola con php -v que el binario en ejecución corresponde a la versión parcheada (8.5.12, 8.4.27, 8.3.36 o 8.2.35).

Atención a servidores antiguos: Los servidores que aún corran sobre Ubuntu 20.04 o anterior no pueden recibir esta actualización por las vías estándar de Forge. La recomendación oficial es aprovisionar un nuevo servidor con una versión soportada de Ubuntu (22.04 LTS o 24.04 LTS), migrar los sitios y apagar la instancia antigua.
Laravel Cloud y Laravel Vapor

• Laravel Cloud: Aplicó los parches in-place de forma transparente tanto para PHP como para Node.js sin necesidad de redesplegar las aplicaciones.
• Laravel Vapor: Los runtimes nativos parcheados (PHP 8.2+) están disponibles, pero requieren lanzar un redeploy manual de cada aplicación (o un nuevo deployment completo si utilizas imágenes Docker personalizadas). Vapor no dispone de parche para PHP 8.0 ni 8.1.

Mitigaciones temporales (si no puedes actualizar de inmediato)
El equipo de PHP ha sido tajante: no existe ninguna mitigación por configuración que sustituya al parche. Actualizar el binario de PHP es la única solución real.
No obstante, en sistemas heredados donde la actualización requiera una ventana de mantenimiento compleja, el aviso de seguridad detalla ajustes para reducir la superficie de exposición:
Para mitigar CVE-2026-109618 (Corrupción OOM):

• Desactivar el límite de memoria interno de PHP: Configurar memory_limit=-1 a nivel de sistema (por ejemplo, usando php_admin_value en el pool de FPM o en la configuración de servidor) para que las aplicaciones no puedan sobrescribirlo y evitar que salte el manejador OOM vulnerable de PHP.
• Delegar el límite de memoria al sistema: Controlar el consumo mediante límites de contenedor o cgroups (evitando RLIMIT_AS o RLIMIT_DATA, ya que estos provocan exactamente el fallo de asignación de memoria vulnerable).
• Restringir el tamaño de las peticiones: Reducir post_max_size (por ejemplo, a 8M en APIs o aplicaciones sin subida de archivos, y 32M donde sea necesario) manteniendo upload_max_filesize por debajo de ese umbral, y aplicar límites estrictos en Nginx o el proxy inverso (Cloudflare) sobre el tamaño del cuerpo, número de cabeceras y partes multipart.

Para mitigar CVE-2026-109619 (Estado global obsoleto):

• Deshabilitar el progreso de subida en sesión: Establecer session.upload_progress.enabled=0 directamente en php.ini o en la configuración del pool de FPM y reiniciar los workers (aplicarlo mediante ini_set() o .user.ini actúa demasiado tarde en el ciclo de la petición).
• En PHP 8.5: Establecer fatal_error_backtraces=0 y reiniciar todos los workers.
• Limpiar directivas obsoletas: Eliminar configuraciones por petición inválidas o deprecated que emitan diagnósticos antes de la inicialización del script.

Conclusión: La importancia del mantenimiento preventivo
Incidentes como el de la semana pasada demuestran que la seguridad de una aplicación web no termina cuando pasamos los tests automatizados o cerramos un repositorio. Puedes tener una arquitectura impecable en Laravel, rutas protegidas y validaciones estrictas, pero si el intérprete de PHP o el sistema operativo subyacente quedan desatendidos, toda la plataforma queda expuesta.
Mantener los servidores en versiones LTS activas de Ubuntu, trabajar sobre ramas soportadas de PHP y contar con un protocolo ágil de actualización en herramientas como Laravel Forge es lo que marca la diferencia entre aplicar un parche en diez minutos o sufrir una brecha crítica en producción.