Dos RCE críticas en PHP: quién está expuesto y en qué orden parchear

El 21 de octubre de 2026 el proyecto PHP publicó 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y su aviso lo dice sin rodeos: actualiza ya. Estas versiones corrigen dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación, y el aviso considera en riesgo cualquier instalación de PHP que atienda peticiones web: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Si usas Laravel, WordPress o cualquier otra cosa sobre PHP, esto va del runtime que hay debajo de tu código, no de tu código. Tu aplicación no tiene que tener ningún fallo para que te afecte.

Qué son los dos bugs

CVE-2026-109618 tiene que ver con cómo se gestiona la falta de memoria. Un fallo de asignación puede interrumpir PHP cuando los datos internos de la petición están a medio preparar, y la limpieza al final de la petición puede tratar luego esos datos a medias como válidos. El aviso de GitHub añade que varias rutas del análisis de subidas multipart pueden llegar a ese estado sin memoria mientras la petición todavía parece dentro de sus límites. CVE-2026-109619 tiene que ver con estado obsoleto: algo que pertenece a una petición puede sobrevivir a la memoria que lo sostiene, y la siguiente petición que atiende el mismo worker puede usarlo antes de que la inicialización normal lo reinicie.

El tracker externo pwn.watch llama a la pareja "PHP2Shell", les da a ambas un CVSS de 9.2 y dice que los detalles salieron antes de tiempo por una filtración durante el embargo. Según ese mismo tracker, hubo intentos de explotación antes y después del parche, watchTowr y AWS informan de escaneos activos, y fabricantes de appliances como QNAP aún estaban preparando sus arreglos. Esas son afirmaciones del tracker; lo que tienes que instalar te lo dice el aviso de php.net.

Qué configuraciones están más expuestas

El riesgo no es igual para cada API de servidor. El aviso de GitHub explica por qué: mod_php siempre ejecuta el cierre de la petición aunque su arranque haya fallado, así que quedarse sin memoria al analizar el cuerpo lleva a procesar un estado inválido antes de que se ejecute ningún código de la aplicación, y ahí se demostró un exploit funcional. PHP-FPM termina el proceso hijo cuando falla el arranque, lo que lo saca del pool; según el análisis del código fuente FPM sigue siendo vulnerable, pero no se mostró ningún exploit completo para él. FrankenPHP probablemente es vulnerable de la misma forma que mod_php, y el LSAPI de LiteSpeed se comporta como FPM.

Encuentra cada PHP y parchea en orden

Por regla general, en un servidor puede haber más de un PHP, y php -v en una terminal te dice la versión del binario de línea de comandos, que no siempre es la que usa el servidor web. Revisa cada sitio donde puede esconderse una versión: la CLI, el servicio FPM, cada imagen de Docker que construyes o descargas, y el selector de PHP del panel de hosting.

# the command-line PHP (may differ from the web one)
php -v
# the PHP inside a container image you deploy
docker run --rm your-image:tag php -v

Para saber qué versión ejecuta de verdad el servidor web, un archivo temporal te lo dice en una sola petición. Bórralo justo después.

<?php
echo PHP_VERSION, ' ', PHP_SAPI;

Cualquier versión por debajo de 8.2.35, 8.3.36, 8.4.27 o 8.5.12 está afectado. Las distribuciones de Linux y los proveedores de soporte a largo plazo recibieron los parches por adelantado, así que mira primero los paquetes de tu proveedor. El aviso señala que rpms.remirepo.net, mantenido por voluntarios, no tendría las actualizaciones el día del lanzamiento, y sugiere en su lugar los paquetes de la distribución o compilar desde el código fuente. PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP; algunos proveedores hacen backports, y el equipo de seguridad publicó backports mínimos del código fuente para 7.4, 8.0 y 8.1 para quien compila por su cuenta.

Después de actualizar, reinicia cada worker de PHP. Un pool de FPM que lleva tiempo en marcha o un worker de FrankenPHP mantiene el binario antiguo en memoria hasta que se reinicia.

Lo que hacen las mitigaciones y lo que no

El aviso es directo en esto: actualizar es la única solución completa, y las medidas que enumera reducen la exposición en rutas concretas sin hacer segura una instalación. Para el bug de memoria incluyen: memory_limit=-1 donde las aplicaciones no puedan sobrescribirlo (php_admin_value en el pool de FPM o en la configuración de Apache), un post_max_size bajo (8M sin subidas, 32M con ellas, y upload_max_filesize por debajo), límites en el servidor web o el proxy para el tamaño de la petición, el número de campos, las partes multipart, las cabeceras y el anidamiento, y un límite de memoria del contenedor o del cgroup en lugar de RLIMIT_AS o RLIMIT_DATA, que pueden provocar justo el fallo de asignación del que hablamos. Para el bug de estado obsoleto: session.upload_progress.enabled=0 en php.ini o en la configuración del pool (no con ini_set() ni .user.ini) reiniciando después cada worker, fatal_error_backtraces=0 en 8.5, quitar los ajustes por petición inválidos u obsoletos, y corregir los errores fatales y timeouts que un atacante pueda alcanzar.

El paso concreto de hoy: haz una lista de cada servidor, imagen de contenedor y cuenta de hosting que ejecuta PHP, apunta la versión que sirve cada uno y actualiza los que estén por debajo de las versiones corregidas antes de tocar ningún ajuste. Fuente: php.net, aviso de seguridad del 21 de octubre de 2026.