PHP corrigió dos fallas críticas que permiten ejecutar código en servidores web sin contraseña y pidió actualizar ya

El proyecto PHP publicó el miércoles 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 de ese lenguaje de programación, con las que corrige dos vulnerabilidades críticas que pueden permitir a un atacante ejecutar código en un servidor web sin necesidad de usuario ni contraseña. «Se recomienda enfáticamente a todos los usuarios de PHP actualizar de inmediato», dice el aviso de seguridad del equipo del proyecto^[1].

Las fallas quedaron registradas como CVE-2026-109618 y CVE-2026-109619. Ambas recibieron 9,2 puntos sobre 10 en la escala CVSS versión 4.0, con la calificación de severidad «crítica», según los avisos técnicos que el proyecto publicó en GitHub^[3][4]. El equipo había anticipado el lunes 20 que la actualización saldría al día siguiente a las 14:00 en hora universal (11:00 en la Argentina) y que se reservaba adelantarla si los detalles se hacían públicos o aparecían pruebas de explotación activa^[2].

Qué hacen las dos fallas

La primera, CVE-2026-109618, está en el manejo de la falta de memoria. Cuando PHP se queda sin memoria a mitad de un pedido, interrumpe el proceso de golpe; si eso ocurre mientras ciertos datos internos están a medio preparar, la limpieza posterior puede tratarlos como válidos. El aviso describe cómo forzar esa situación con formularios de envío de archivos armados a propósito, aun dentro de los límites que fija la configuración^[3].

La segunda, CVE-2026-109619, se produce porque un proceso de PHP puede conservar datos de un pedido anterior que apuntan a memoria ya liberada. Un pedido posterior atendido por el mismo proceso puede usarlos antes de que se reinicien. Para aprovecharla, el atacante necesita dos pedidos que caigan en el mismo proceso: uno que deje los datos viejos y otro que los use^[4].

Según el proyecto, están expuestas todas las formas habituales de ejecutar PHP en un servidor web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es mayor con mod_php, donde los investigadores demostraron un ataque en el que un pedido sin autenticación dispara la falla antes de que corra el código de la aplicación^[1]. En PHP-FPM, la segunda falla fue validada a través de la función de progreso de subida de archivos; para la primera, el aviso la considera vulnerable por análisis del código, aunque no se demostró un ataque completo^[3][4].

Las fallas fueron reportadas por investigadores de Wiz Research, de OpenAI Codex Security y de la firma Calif, que también contaron con la colaboración del equipo de Gemini de Google, según el sitio que Wiz publicó sobre el caso con el nombre «PHP2Shell». Allí los investigadores afirman haber ejecutado código sin autenticación, en entornos de prueba, en sitios armados con WordPress, Drupal y Joomla, aunque aclaran que el ataque no depende de esas aplicaciones porque la falla está en el núcleo de PHP. Según el mismo sitio, las versiones afectadas se remontan a PHP 5.4^[9][3].

Ni el aviso de PHP ni los informes técnicos dicen que las fallas estén siendo explotadas por atacantes. El catálogo de vulnerabilidades explotadas de la Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos (CISA), en su versión del 21 de octubre, no las incluye^[1][3][4][5].

Qué tienen que hacer los administradores

La única solución completa es actualizar, insisten los avisos^[1][3][4]. Quien use paquetes de una distribución de Linux debe instalar los de su proveedor, que recibieron los parches por adelantado. Ubuntu, que calificó la falla de prioridad crítica, publicó el mismo 21 los avisos USN-8948-1 y USN-8948-2, con paquetes corregidos para sus versiones 22.04, 24.04, 26.04 y 26.10, y para versiones más viejas a través de su suscripción Ubuntu Pro^[6]. Debian corrigió sus versiones estables 12 y 13 (avisos DLA-4848-1 y DSA-6574-1), mientras que su rama de pruebas seguía vulnerable^[7].

PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto. Por la gravedad del caso, el equipo de seguridad publicó parches mínimos de código fuente para 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta o no tiene un proveedor con soporte extendido^[1]. La rama 8.2 tiene soporte de seguridad hasta el 31 de diciembre de 2026; la 8.3, hasta fin de 2027; la 8.4, hasta fin de 2028, y la 8.5, hasta fin de 2029^[8].

Para quien no pueda actualizar enseguida, el proyecto enumera medidas que reducen la exposición pero, advierte, «no hacen segura una instalación»: quitar el límite de memoria de PHP, bajar el tamaño máximo de los envíos (8 MB si la aplicación no recibe archivos, 32 MB si los recibe) y limitar el tamaño de los pedidos en el servidor web, contra la primera falla; y desactivar el progreso de subida de sesiones y, en PHP 8.5, los rastreos de errores fatales, y reiniciar todos los procesos, contra la segunda^[1].

La versión de prueba PHP 8.6.0 RC4, publicada el mismo día, ya trae las correcciones^[1].