El 21 de octubre de 2026, PHP publicó actualizaciones de emergencia para CVE-2026-109618 y CVE-2026-109619. Ambas vulnerabilidades tienen una puntuación CVSS v4.0 de 9,2 y pueden permitir ejecución remota de código sin autenticación en las instalaciones afectadas. El alcance incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera que mod_php es la configuración más expuesta porque una petición anónima puede llegar al ciclo vulnerable antes de que se ejecute el código de la aplicación.

CVE-2026-109618 afecta a la gestión de memoria después de un fallo de asignación. Una estructura multipart compleja, muchos encabezados dentro de las partes, nombres de campos anidados y otras asignaciones controladas por el atacante pueden llevar a PHP a una condición de falta de memoria. La limpieza posterior puede tratar datos de la petición que no se inicializaron por completo. El impacto confirmado es la ejecución de código con la cuenta del proceso web.

CVE-2026-109619 se debe a un estado de la petición que permanece más tiempo del debido. Un worker de larga duración puede conservar un puntero a memoria liberada tras una petición anterior. Una petición posterior encuentra entonces una condición de use-after-free. PHP confirmó una vía relacionada con los backtraces de errores fatales en PHP 8.5 y otra relacionada con el progreso de subida de sesiones. El problema general no se limita a un ajuste o una extensión concretos.

El fallo está en el runtime de PHP, no necesariamente en WordPress, Laravel, Magento o un plugin. Una aplicación actualizada puede seguir ejecutándose sobre un binario de PHP vulnerable. La petición puede llegar al fallo mediante un script pequeño, una ruta de comprobación, un formulario de acceso o un endpoint de subida antes de que el framework genere sus registros normales. Cloudflare relacionó los escenarios con la memoria, los errores y el estado de las peticiones HTTP.

Las versiones corregidas son PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 y PHP 8.2.35. El proyecto PHP ya no proporciona correcciones para PHP 8.1 y versiones anteriores. Algunos proveedores de sistemas operativos y soporte a largo plazo pueden aplicar parches retroportados. Por eso, el changelog del paquete y el aviso del proveedor son más fiables que la versión visible de upstream.

Según la PHP Foundation, los primeros indicios del problema de memoria aparecieron durante una auditoría externa en 2024. Calif, OpenAI y Wiz demostraron posteriormente una vía fiable hacia la ejecución de código. Los parches cambian el tratamiento de las situaciones de falta de memoria y reinician un conjunto más amplio de estados globales propios de las peticiones. Una ruta de falta de memoria diferida y una terminación forzada segura evitan que el cierre procese un estado inválido.

Actualizar los archivos no basta. Los operadores deben identificar el runtime y el origen de los paquetes que sirven cada aplicación pública, instalar un paquete o una imagen de contenedor corregidos y reiniciar Apache, PHP-FPM, los workers CGI, FrankenPHP, LiteSpeed y cualquier otro proceso PHP persistente. Después deben comprobar el binario activo y el changelog del paquete. Las pruebas deben cubrir subidas, sesiones, colas y trabajos en segundo plano. Los registros anteriores al parche deben conservarse antes de la rotación habitual.

PHP presenta la actualización como la única mitigación completa. Mientras llega el parche, unos límites prudentes para el tamaño de las peticiones y la complejidad multipart pueden reducir la exposición. Eliminar fallos previsibles de memory_limit controlados por el atacante puede ayudar. PHP desaconseja sustituir esa medida por RLIMIT_AS o RLIMIT_DATA, porque esos límites pueden activar la ruta de fallo de asignación que corrige el parche. Hay que desactivar session.upload_progress.enabled y reiniciar todos los workers. En PHP 8.5 también se debe desactivar fatal_error_backtraces. Estas medidas bloquean rutas confirmadas, pero no cubren todas las posibles fuentes de estado obsoleto.

Cloudflare informó de reglas WAF que combinan señales de petición y respuesta. AWS describió el bloqueo o la detección de intentos conocidos. Estos controles aportan defensa en profundidad, pero no sustituyen la actualización del runtime. Si no es posible aplicar el parche de inmediato, conviene reducir la accesibilidad mediante una VPN, una allowlist o un control de acceso autenticado en el borde. El origen no debe poder alcanzarse directamente. Hay que desactivar las subidas multipart innecesarias, retirar secretos que el worker no necesite y limitar sus privilegios del sistema operativo y de red. Deben conservarse los registros web, PHP, proxy, procesos y autenticación.

Amazon Threat Intelligence informó de un intento de explotación de PHP2Shell contra su honeypot MadPot el 17 de octubre, cuatro días antes de la divulgación pública. Después observó varios intentos de prueba de concepto procedentes de distintas infraestructuras anonimizadas cerca de la publicación. Amazon no pudo determinar si el intento anterior habría funcionado contra un objetivo real. Las organizaciones deberían investigar desde el 17 de octubre o desde la fecha más temprana registrada por sus propios proveedores de inteligencia.

La búsqueda debe incluir telemetría de procesos, registros de reverse proxy y errores de PHP, datos de detección en endpoints y alertas de integridad de archivos. Son indicios relevantes los workers web que lanzan shells o herramientas de red, los fallos repetidos de memory_limit, las respuestas HTTP 500, los bloqueos, los reinicios inusuales y las peticiones multipart anómalas. También deben revisarse archivos nuevos en las raíces web, directorios temporales o rutas de inicio, conexiones salientes inesperadas, credenciales o tareas programadas nuevas y accesos fuera de patrón a secretos, certificados o bases de datos. Un registro limpio de la aplicación no descarta actividad en el runtime.

La respuesta comienza con un inventario de todos los servicios PHP accesibles desde Internet. Debe incluir contenedores, máquinas virtuales, hosting compartido, paneles de control, appliances, subdominios antiguos, entornos de staging e instalaciones gestionadas por proveedores. Para cada servicio hay que registrar el SAPI, el origen del paquete, el estado del parche, el método de reinicio y el responsable. Los sistemas públicos con mod_php o PHP-FPM tienen prioridad, especialmente si aceptan subidas. Ante una ejecución sospechosa, hay que aislar el host, capturar evidencias volátiles cuando sea posible, rotar las credenciales expuestas y seguir el proceso de respuesta sin borrar los artefactos en el mismo lugar.

PHP2Shell demuestra que los procesos worker también deben tratarse como límites de seguridad. La explotación depende de la compilación de PHP, el SAPI, las extensiones, el allocator, la configuración frontal, la reutilización de workers y la ruta exacta de la petición. Por eso no todos los servidores están comprometidos automáticamente. El estado de actualización de la aplicación no basta para valorar el riesgo del runtime. Los paquetes, los privilegios de los workers, las conexiones salientes y la creación de procesos por identidades web requieren revisiones periódicas.