Lanzamiento de emergencia de PHP: dos RCE críticos corregidos en 8.2.35 a 8.5.12
PHP ha publicado un lanzamiento de seguridad fuera de ciclo que corrige dos vulnerabilidades críticas de use-after-free en el núcleo del lenguaje, ambas explotables para la ejecución remota de código sin autenticación y ambas con 9,2 en la escala CVSS v4.0. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas hoy y listadas en el archivo de lanzamientos del proyecto. Los backports mínimos de código fuente para las ramas 7.4, 8.0 y 8.1, sin mantenimiento desde hace tiempo, están solo en GitHub: no existen binarios oficiales para ellas.
El lanzamiento vino precedido de una ventana de divulgación caótica. El 20 de octubre el proyecto anunció una publicación de emergencia para hoy a las 14:00 UTC sin nombrar versiones ni funciones afectadas; tal como documentó OX Security, capturas de una herramienta de explotación circularon antes de que los parches estuvieran disponibles, y el propio proyecto advirtió que el código proof-of-concept que circula en esa ventana suele ser malware disfrazado. Ahora que los parches y avisos son públicos, el panorama técnico es más claro de lo que sugería el ciclo de adelantos.Un camino de falta de memoria hacia la ejecución de código
CVE-2026-109618, registrada como GHSA-w8hw-w9fx-j79w, abusa de cómo PHP maneja el agotamiento de memoria. Cuando una asignación falla, el motor desenrolla la petición con un longjmp(); si eso ocurre mientras la memoria de la petición está solo parcialmente inicializada, la fase de cierre lee o ramifica después sobre memoria en estado inválido. El aviso describe una familia de trucos de presión de asignación que hacen esto alcanzable desde una petición HTTP ordinaria: cuerpos multipart sin un content-length utilizable que se escurren pasado post_max_size, partes con miles de cabeceras cuya representación en memoria supera con creces su tamaño en el cable, y controles de archivo vacíos que reservan arrays de metadatos sin contar jamás contra max_file_uploads. El SAPI mod_php de Apache está confirmado como explotable: los investigadores validaron ejecución remota de código sin autenticación como la cuenta del worker web sobre HTTP plano con configuraciones prefork por defecto, aunque con alta complejidad de ataque y posiblemente varios intentos. Se considera susceptible PHP-FPM vía rutas de asignación específicas de la aplicación, y probablemente también FrankenPHP y LiteSpeed. El parche sustituye el longjmp crudo por una trampa suave de falta de memoria en el siguiente punto seguro de la VM, más un fallo duro que mata el worker directamente.Estado obsoleto en procesos worker
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) es la hermana silenciosa: los procesos worker arrastran estado global -manejadores de errores, datos de sesión, contabilidad de objetos y extensiones- que puede acabar apuntando a memoria propiedad de una sola petición. Si un error fatal, un aborto por falta de memoria o un diagnóstico tardío escribe ese estado y nada lo reinicia antes de liberar la memoria de la petición, los globales del worker quedan colgando. Lo primero que los toque antes de que se inicialice una petición nueva leerá memoria liberada. Dos rutas de producción están confirmadas: las trazas de error fatal, nuevas en PHP 8.5, bajo mod_php, y el mecanismo session upload progress bajo mod_php y FPM. Productor y consumidor deben caer en el mismo proceso worker, lo que hace más difícil -no imposible- acertar en pools FPM con muchos workers.Un diseño de heap estratégicamente elaborado puede producir ejecución remota de código (RCE) completa. - Aviso de seguridad de PHP, GHSA-6wmf-4rv5-p3rp
Lo que los administradores deben hacer ahora
Actualizar es la única mitigación completa, y no es un asunto de parchear y olvidar: ambos avisos subrayan reiniciar todos los workers de PHP tras actualizar, porque el estado obsoleto puede sobrevivir en procesos de larga vida. Las ramas soportadas tienen binarios de lanzamiento; los sitios anclados a ramas EOL deben aplicar los backports de código fuente por su cuenta.- Actualizar a 8.2.35, 8.3.36, 8.4.27 u 8.5.12 (o aplicar los backports de GitHub para 7.4/8.0/8.1) y reiniciar después todos los procesos worker.
- Si actualizar hoy no es posible: fijar session.upload_progress.enabled=0 y, en PHP 8.5, fatal_error_backtraces=0, y reiniciar los workers.
- Para la vulnerabilidad OOM, imponer memory_limit=-1 de forma centralizada y verificar que ningún override de pool o .htaccess restaure un límite finito.
- Mantener un post_max_size conservador, bloquear en el frontend las peticiones multipart si la aplicación no las usa y limitar variables de entrada, cabeceras y subidas.
- Usar límites de memoria de contenedor o cgroup en lugar de RLIMIT_AS o RLIMIT_DATA: el aviso advierte explícitamente de que los mecanismos RLIMIT empujan los fallos de asignación hacia la ruta vulnerable.
- Opcionalmente, limitar el reciclado de workers con pm.max_requests para acortar la ventana de arrastre de estado.