PHP parchea dos RCE críticas y revela otro vector ligado a sesiones
PHP corrigió dos vulnerabilidades críticas que permiten ejecución remota sin autenticación y publicó un aviso adicional para una configuración de sesiones poco habitual. Las ramas 8.5, 8.4, 8.3 y 8.2 tienen versiones corregidas; las mitigaciones reducen rutas concretas, pero la actualización sigue siendo la solución completa.
El equipo de PHP publicó el 21 de octubre actualizaciones para dos fallos críticos que podían permitir ejecución remota de código sin autenticación. Las correcciones llegaron a PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Dos días después, el proyecto añadió un tercer vector relacionado con sesiones: no afecta a cualquier instalación y no recibió un parche fuera de ciclo, pero obliga a revisar una combinación concreta de configuración y código.
Dos fallos, dos rutas muy distintas
CVE-2026-109618 aparece cuando PHP gestiona una falta de memoria durante una petición. Si el fallo interrumpe el procesamiento mientras los datos internos todavía están a medio inicializar, el código de limpieza puede tratar como válido un estado que no lo es. CERT-EU describe corrupción de memoria durante la ruta de error; el impacto no depende de que la aplicación llegue a ejecutar su lógica normal.
CVE-2026-109619 sigue otra ruta: estado global obsoleto entre peticiones. Un error fatal puede dejar referencias internas de una petición después de liberar la memoria que las sostenía; una petición posterior atendida por el mismo worker puede reutilizar ese estado antes de que PHP lo reinicialice. Los dos fallos afectan a instalaciones que sirven peticiones web, incluidos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera mod_php el escenario de mayor riesgo y afirma que una petición no autenticada puede disparar el problema antes del código de la aplicación.
-SecureCrew dice: El parser no necesita saber qué framework tienes instalado para tropezar con el motor que lo ejecuta; el inventario del runtime también cuenta.-
Los arreglos están disponibles en las ramas mantenidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores ya no reciben correcciones upstream; algunas distribuciones y proveedores LTS sí pueden publicar backports, así que el número base por sí solo no demuestra que un paquete siga vulnerable. PHP también ofreció backports mínimos para ciertas ramas antiguas a quienes compilan desde fuente sin proveedor LTS. En producción, hay que comprobar el paquete de la distribución y su aviso, no comparar a ciegas con el número del sitio php.net.
-SecureCrew dice: Un “8.1” en el inventario puede esconder un backport correcto o un paquete sin corregir; la etiqueta sola no hace de análisis de vulnerabilidades.-
El aviso nuevo tiene una condición estrecha
El 23 de octubre PHP informó de CVE-2026-115560, otro vector potencial de RCE. Para que aplique, la aplicación debe configurar el serializador de sesiones como php_binary o php_serialize, cambiarlo después a php mediante ini_set() antes de llamar a session_start(), y mantener activa la función de progreso de carga de sesiones. El proyecto describe esta combinación como inusual y prevé documentar el fallo completo en la siguiente versión regular; no es correcto presentar este aviso como una tercera RCE general para cualquier instalación.
PHP recomienda desactivar session.upload_progress.enabled mientras llega esa versión si se necesita cerrar temporalmente esa ruta. La medida es específica y provisional: no sustituye las actualizaciones de las dos RCE corregidas, ni obliga a deshabilitar la función en aplicaciones que no cumplen la condición descrita. Para CVE-2026-109619, PHP mantiene también esa opción entre sus mitigaciones para ciertos caminos, pero indica que debe aplicarse desde configuración efectiva antes de analizar la petición y que los workers deben reiniciarse. La corrección completa sigue siendo el parche.
Qué conviene comprobar hoy
CERT-EU recoge que ya circulan pruebas de concepto para los dos fallos iniciales y recomienda priorizar los servidores expuestos. Una PoC publicada no acredita por sí sola intrusiones, aunque reduce el margen cómodo para posponer la actualización. PHP tampoco afirma en su aviso que todos los despliegues hayan sido atacados; conviene revisar registros y alertas según la exposición y la telemetría disponible.
Empieza por inventariar las versiones realmente cargadas por FPM, Apache o el servidor CGI, incluidas imágenes y paquetes de terceros. Después verifica el aviso del proveedor del sistema operativo, despliega la versión corregida o su backport y reinicia los procesos PHP afectados para que carguen el binario nuevo. Si la aplicación usa la combinación de serializador descrita, aplica además la mitigación temporal desde configuración central y registra qué servicio la recibió.
-SecureCrew dice: Cambiar el paquete sin reciclar el worker deja al proceso viejo atendiendo peticiones con una confianza muy nueva.-
Parchear no demuestra que una instalación estuviera limpia antes de actualizar. En activos de alta exposición, la revisión de errores fatales, peticiones de carga y actividad anómala debe acompañar el cambio; un hallazgo en registros necesita investigación, no una atribución automática a estos CVE. El aviso del 23 de octubre tiene alcance limitado, pero es una buena prueba de que “la versión ya está parcheada” y “la configuración no abre una ruta distinta” son comprobaciones separadas.
Diccionario de la Crew
RCE — Ejecución de código controlada por un atacante en el sistema afectado.
OOM — Falta de memoria disponible durante una operación del proceso.
FPM — Gestor FastCGI que ejecuta PHP en procesos worker.
Worker — Proceso que atiende peticiones; FPM puede mantenerlo activo entre varias.
PoC — Prueba de concepto que muestra una técnica, sin demostrar por sí sola explotación en una víctima.
